Author: devopsy.kinsta.cloud

  • Creating Software-First Businesses with SDM

    Creating Software-First Businesses with SDM

    Organizations striving to be “software-first” businesses are focusing their investments narrowly – on creating the best development and deployment practices they can. They’re implementing DevOps cultures, standing up CI/CD pipelines, integrating new sets of tools, training staff, and organizing new procedures – all to make software delivery more efficient.

    To an extent, the moves are paying off. Tech leaders such as Netflix and Facebook are releasing multiple times per day, and cloud-native development initiatives are helping newcomers become more nimble. Organizations of all sizes and scope are deploying code faster, failing less, and recovering more quickly from downtime than ever before.

    But is the software-first movement succeeding in its larger mission – to deliver quality apps that impress end users and generate optimal value for organizations themselves? That’s a question that stretches beyond metrics. It zeroes in on how organizations define the actual software delivery function and how high a priority they put on that function. Does software delivery begin and end in the DevOps process?

    Or does it extend in both directions – further left, to how the product is envisioned, planned and prioritized, and right, to the way it’s marketed and sold – and back through a rapid feedback loop,  to be continuously improved? Are organizations committing to sustaining end-to-end software delivery systems that remove any blockers?

    They try. But they’re hamstrung by the toolsets and processes that govern today’s software sector. As organizations grow their DevOps maturity and then attempt to scale into the software-first mode, most will hit a ceiling. Unless they’re able to a) measure, manage and continuously improve their core CI/CD capability, b) fully connect software development efforts to the broader product and software organization, and then c) ultimately connect those efforts to the rest of the business responsible for bringing software successfully to market, they’ll fall short and no longer be competitive.

    The root cause of this disconnect is that information is locked into stand-alone software tools and isolated within teams and functional groups. The teams have their mandates, and work within silos, without common processes, a common data model, a common language, or universal, shared insights. They collaborate amongst themselves but not as well with other teams and other functions across the organization. If they can’t work together, talk to each other, or share information, they’re flying blind. They don’t have the visibility they need to continuously increase and augment the value generated by the software.

    This problem, of course, isn’t new. Organizations have been hunting for a software delivery “holy grail” for years. Plenty of SDLC/ALM fads based on shiny new “fully integrated” and opinionated tools end up costing money and wasting effort without generating much true value. All-in-one solutions usually involve ripping out the trusted tools, forcing engineering and development teams to learn a whole new way of work. They might be able to streamline some procedures within a small segment of the delivery process — but prevent using the right tool that best gets the job done, ultimately slowing things down.

    What’s needed is a management layer that connects – and guides – all the functions related to software delivery. Here’s a look at a new concept called Software Delivery Management (SDM) that proposes a way to do this. It’s not a set of tools. It’s not based on proprietary technology. It’s not another process. It’s a foundation that brings organizations tools, teams, and processes together.

    Software Delivery Management

    Software Delivery Management (SDM) is a way of connecting teams and tools across an organization, enabling visibility, collaboration, and governance through a unified process and common data, to deliver better software faster, resulting in increased value to the customer and measurable business outcomes.

    Just like DevOps breaks down the walls between the development and operations teams, SDM breaks down the walls between development, product management, UIX teams, documentation teams, support, and product marketers. It allows them to communicate better, understand each other’s needs, and ultimately make software that isn’t just bug-free, but also effectively addresses the business needs and creates value for the customer.

    How do organizations build an SDM function? They can start by creating systems that enable the four pillars of an SDM model – common data, connected processes, universal insights, and all functions collaborating.

    Establish a system of record: Build or buy a system of record with a common data model that brings in your different data elements. This would include a persistent and extensible data store, modeling software delivery lifecycle entities, and recording all software delivery activity to support subsequent queries, visibility, analytics, insights, and workflow orchestration. You can organize that data in a common model and language that everyone can access.

    Have a flexible common data model to get universal insights: Either through APIs or some other way, you need to be able to connect different tools. The idea is to go beyond just your DevOps toolchain and bring in information from data sources such as CRM, Financials, and Support. Then you find a way to leverage that data – either through queries which then could bring invisibility or through insights that could then be turned into a policy.

    Find a way to bring those things together. It’s the only way you can democratize that information so the development teams understand who’s doing what and when and with different components. Then your different stakeholders – product marketing, sales, customer success management, support – also have a view into this data. They may get it through a weekly report that someone is manually putting together and pushing out. But it still enables that visibility so people can plan and support the big initiatives that software delivery is putting together for a particular set of users or customers as improvements over what they’re using today.

    SDM in Action

    How does SDM work in practice? Here’s a hypothetical example of how a typical software delivery organization gets blocked by existing practices and how a software delivery management layer might help remove those blockers.

    Let’s say the Product Leader at a music delivery business wants to upgrade a music player by adding three principal features: a better UI, an improved editing function, and a different way to package a playlist. Without an SDM strategy, this would likely be written in a standalone document as a set of complex requirements and then sent to the development team — and the dev team has no context on why the features are important. The Dev team would translate the requirements into a tracking system as user stories or features but without a complete understanding of the customer and business drivers. The fact that the CEO’s idea comes from data pulled from customer support tickets and RFEs is completely obscured.

    Unfortunately, the display and editing capabilities weren’t expressed clearly in the original requirements document, and even more, was lost in the translation into stories. This gap goes unnoticed. The playlist capabilities were implemented incorrectly. The project is released to customers, but adoption is lackluster. Instead of the hoped-for reduction in support requests, support teams get a flood of requests from customers who don’t understand the user interface or are having problems getting it to work.

    Meanwhile, a competitor who had the same market challenge releases a new set of features. The competitor’s new capabilities aren’t the same, but they meet the same customer needs. At first, the competitor also sees weak adoption but can rapidly integrate the feedback from the sales and support teams into new releases. After fixing the confusing user interface and providing appropriate documentation for the product marketing team, adoption soars. The competitor wins industry innovation awards, and our CEO’s music delivery company loses customers, revenue, and possibly even key developers who leave to work for the competitor.

    If developers had known at the beginning why the new features were being developed, could they have suggested tweaks that deliver the same business goals? Better yet, had they understood the customers’ need, they may have been able to suggest an alternate approach that was even better. If support and development had access to common information and connected processes, could they have collaborated better? This is why it is important to bring development teams into the mainstream of business operations and planning.

    SDM Strategy Adopted

    If the music delivery company followed a Software Delivery Management strategy, the entire software development organization, and related areas would engage when the data from customer support was being discussed, before the display, editing, and playlist capabilities were settled on. Instead of a requirements document being thrown over the wall, development and product stakeholders would be able to engage in a conversation and have the context related to the business needs the features are being designed for.

    Each story assigned to a developer would be linked back to a concrete business goal with the associated customer, market research, and expected outcomes. The developer would have the context and insights necessary to build and deliver the right functionality that meets customer requirements. Support could weigh in with input they have received from customers about the new functionality. Finally, the field organization could share what they have been hearing and seeing in customer and prospect accounts they have visited.

    When the conversation about business goals and customer impact includes development, product management, UIX teams, doc teams, support teams, product marketers, and the field organization, everyone gets a more complete picture of how a feature is or is not meeting customer desires. Together, they can determine the best way to meet the business goals creatively and efficiently. If a feature isn’t working for end-users, that information is surfaced quickly and immediately integrated into future iterations.

    If development on a particular feature has a bottleneck or blockage – a security vulnerability, a code quality issue, or a pull request waiting for review in the repository connected to this feature – information may be in the tools today, but it’s not surfaced centrally in the context of a feature. With SDM, multiple teams can see this immediately and act proactively immediately.

    This will help the scrum team assess any potential blockers to surface this immediately, while you’re working, bringing this information transparently to the teams. If such blockers become a frequent issue, a good way to manage this is through the use of policies.  Implementing policies along the software development process can help teams work more efficiently while also ensuring specific actions are taken promptly, or certain thresholds are met before moving to the next stage.  The result is delivering quality, secure software to customers.

    SDM also gives management the ability to assess the organization’s performance in different ways. In specific teams, tooling is in place to assess those teams’ efficiencies. But how did the business performance across multiple teams, across multiple workstreams, using different tools? It becomes more and more difficult to assess this holistically in one single place and connect it properly. And then, from that analysis, how did the business perform to create this output?

    This goes into the CD and the CD process. Then from there, it lands in front of the customer. Who has access to it? Is it feature flagged? Is it accessible to everyone? What is the performance of this feature after we’ve implemented our improvement, our enhancement, or our new feature? How does this relate to what we set out to do – to improve the player’s user experience and to increase the engagement for our users? Can we measure this?

    SDM gives more stakeholders more visibility into what others are doing. It’s really about sharing information to collaborate better – the intersection points between teams and roles and people. Like between Dev and Ops, it’s a collaboration between product owner, business and development teams. SDM is about connecting all the roles and functions for the full lifecycle – from ideation, plan, build, test and release,  to realizing value to the business, along with a fast feedback loop to improve. Sales, field, and product marketing can use the information more effectively and plan better around it. Organizations can release products more quickly because of CD, but using SDM they can build supporting processes around it so they’re more effective.

    Software Delivery Management not only allows for better decisions and expectations at the beginning of the software lifecycle – but it also extends the feedback loop throughout the software delivery process, through actual customer success, and back. This provides an endless loop of input about what’s working — and maybe most importantly, what’s not — to drive continuous improvement in software quality and functionality. This reframes the role of software delivery in the enterprise, recognizing it as a key business driver.

    A Post-COVID Future

    Creating a management layer on top of existing processes and tools is important in any environment. It makes sure products are getting out on time, they’re being developed with high quality, they’re secure and they’re meeting the needs of your users. Today, with the disruptions caused by COVID-19, it’s even more important. When you look across your software delivery process, you need to know where things are, where people are, how your work is progressing, and if blockers need to be removed. Manual steps that were OK before aren’t now. You have to automate it.

    That’s where SDM comes into play. CI/CD is all about building the code, testing it, and getting it out. SDM gives stakeholders, both left and right, visibility into every aspect of the software delivery process. By linking information, teams, and processes, organizations get that extra level of visibility and insight to continue to evolve into software-first businesses in the future.

  • Why Software Delivery Management Matters

    Why Software Delivery Management Matters

    Continuous Everything: Why Software Delivery Management Matters

     

    In the DevOps world, implementing continuous integration and continuous delivery (CI/CD) is a long and arduous digital transformation process. That said, many organizations are succeeding and reaping the benefits of automation. Despite an organization’s ability to deliver software faster, there’s still missing gaps from silos that exist between various business functions across the organization. This slows down the flow of information about the software delivery process and hampers the ability to optimize various departmental functions based on lack of – or outdated – information.

    Enter the emerging category of Software Delivery Management (SDM).

    SDM breaks down silos, providing visibility across an organization into the software development lifecycle. It relies on four foundational pillars:

    • Common Data
    • Universal Insights
    • Common Connected Processes
    • All Functions Collaborating

    These pillars support a unified system of record in which all functions can enjoy continuous insights and feedback, resulting in faster software delivery and positive impact on the business.

    To learn more about SDM, this whitepaper will help you understand how and why SDM is evolving and the benefits it will provide to your organization. Break down the silos and see how the business of DevOps and Software Delivery Management can transform your organization into a faster software delivery machine.

    If you’re interested in participating in the CloudBees SDM Platform Preview Program, click on this link.

  • Work from Home Tips

    Work from Home Tips

    Bees have worked remotely since our founding 10 years ago. We have an internal Slack channel used to discuss topics related to working from home. We threw out a question or two, asking the Bees for their best tips and practices to make working from home easier. We got back a ton of responses and wanted to share them with you.

    Do you have any tips of your own to share? Push them out on Twitter and tag us (@CloudBees ). We will select a few to add to this blog!

    Tips and best practices from CloudBees employees:

    COMMUNICATION

    “Send ‘Good morning’ and ‘Have a good night’ chats to the team. You would say good morning to your colleagues when you come into the office so why wouldn’t you still do that when WFH? It informs your team you are online and available or you are done for the day.”
    – Nicole Case, HR Business Partner

    “Create a culture of embracing the distractions of working remote: I can’t tell you how many times seeing someone’s pet or child photobomb a video call is the highlight of the meeting vs. a negative distraction. It puts everyone in a better mood and at ease, knowing that home life distractions are inevitable and are part of this working arrangement.”
    – Nick Rendall, Product Marketing Manager

    “Provide channels that facilitate human bonds…or animal and baby bonds in our case. We have Slack channels for #social-cats, #social-dogs and #social-baBEES. Nothing like the smiling dogs or sweet potato covered babies of your co-workers to brighten your day.”
    – Kristin Baskett, Product Marketing Manager

    “Invest in the gear to work well, remotely. Lots of options here, but doing your best to increase the fidelity of online interactions makes a massive difference in how you are perceived, both internally and to customers (if you interact with them). Even marginal increases in the quality of your interactions matter. Replacing in-person communication is hard, but very possible. This takes consideration and effort.”
    – Kenny Younger, Senior DevOps Consultant

    “Communication tools are not only for talking about tasks, but also for socializing. If I feel depressed or I am just not in the mood, I have work pauses and talk with my fellow team members. Creating relationships is even more important when you work from home.
    – Raul Arabaolaza, Software Engineer

    YOUR WORK SPACE

    “I have a break area setup when I work from home and it is located in another room so I have to get up and move away from the computer. I typically have a jigsaw puzzle that I work on for about 20-30 minutes. It forces me to stop working and shut my brain off from the last meeting. Also, I like to change things in my background to see who’s paying attention on camera. It sort of helps gauge who is watching and listening to me.”
    – Melissa McClure, Manager, Corporate Programs

    “A dedicated home office space is key to being productive at home. It will help reduce the necessary ‘context switching’ that comes with disruptions. If you don’t have a home office and your kids have a desk in their room, use that until they get home from school. Just be mindful that on video conference calls those Hello Kitty and Ant Man posters will be in the background. But they’re a great way to break the ice and relax with your colleagues or customers. We’re all human – celebrate it.”
    – Tim Johnson, Product Marketing Manager

    “Make a room of your home the workplace – preferably with a closing door. I have a makeshift kitchenette in my office with coffee, water cooler, snacks, mini-fridge. Even though the kitchen is just steps away, leaving ‘work’ disrupts your flow state. On the same note, when work is done you can really leave it behind that door. That’s harder to do mentally if you are working at the kitchen table or on the couch.”
    – Kristin Baskett, Product Marketing Manager

    “I have been doing it full-time since 2005 and the tips I have are:

    • Write well
    • Have your own real office space
    • Have two kinds of Internet connections available
    • Don’t work in pyjamas, wear normal clothes
    • Start out with regular timeframes and don’t relax it until you have been working that way for years”

    – Michael Neale, M&A Strategy Director

    “Have a space dedicated to work, and only work there. Do not have things in that space (or visible) that trigger, even subconsciously, non-work stuff. If you can, dedicating a room, or cordoned off portion of a room, is ideal.
    – Kenny Younger, Senior DevOps Consultant

    YOUR MENTAL HEALTH

    “What I found to be the most beneficial when I pivoted to remote work was still getting dressed and ready for work. Even if it’s only work from the waist up, once I gear up my head is in the game.”
    – Rose Becerra, Product Manager

    “Discipline is key. Stay strong and stay on your schedule. Be sure to keep up with exercise, shower, brush your teeth, comb your hair (for those of you that have it) and put on your work clothes. If you dress the part, you will feel the part, you will act the part and will inspire a response from colleagues and customers.”
    – Matt Cillis, VP, North America Sales

    “You need a balance between flexibility and predictability in your working hours to take full advantage of working at home, I usually do most of my work at office hours but I keep my starting and ending time flexible.”
    – Raul Arabaolaza, Software Engineer

    “Time box work. Take a “commute” to and from work each day. Put on your hat when you “leave” home and put it away when you “arrive” later. You have to separate your mind from work to be present at home. This is not only healthy for home life, it’s healthy for your work. You need to take rest from work to do quality work.
    – Kenny Younger, Senior DevOps Consultant

    “On quiet days, when I only have a few minutes of calls, if I am not doing a really mentally challenging task, I like to put some podcasts or YouTube videos in the background. Most of the time I don’t pay attention to them, but I like hearing the voices in the background.”
    – Esther Alvarez Feijoo, Software Engineer

    “There are some meetings that you can have while walking in the garden or any quiet place. It is relaxing and at the same time, healthier.”
    – Raul Arabaolaza, Software Engineer

    “Track your working hours, it’s easy to work more than usual and you need to balance.
    – Raul Arabaolaza, Software Engineer

    “You need a balance between flexibility and predictability in your work hours to take full advantage of working from home. I usually do most of my work during office hours, but I keep my starting and ending times flexible.”
    – Raul Arabaolaza, Software Engineer

    YOUR CHILDREN

    “I saw a posting on Reddit for creating a sane home environment in which kids do chores/homework/exercise to earn privileges for things that want to do (video games, shows, soda). We use monopoly money, not real currency. Day three and its working well with Logan (12 years, boy), Lucca (10 years, boy), and Lilah (7 years, girl)…after the initial resistance.”
    – Michael Bevilacqua, Chief Architect

    “In addition to corporate America suggesting we work from home, some of our schools are now shutting down; so our kids will be with us…at home…all….day…long. If you have young kids, I recommend jointly setting a schedule that includes both playtime and learning time. Have them work on math problems for 30 minutes, then history for 30 minutes, and yes, there’s probably going to be quiet movie time when you’re on that important video conference call.”
    – Todd Stayin*, Senior Customer Success Manager
    *Yes. His real name!

    “Don’t get too rigid with start and finish, there is nothing wrong if you stop one hour in the middle of the afternoon to play with your kids and work back after dinner. But remember the previous point about tracking hours.
    – Raul Arabaolaza, Software Engineer

    PHYSICAL HEALTH

    “I need the dog-walking breaks to keep me sane. When the dog cannot go out (sick, whatever), I can feel it within two days.”
    – Eduardo Pelegri-Llopart, Architect

    “Be sure to take breaks – when you are in the office and have interactions with others you get a break (i.e. get coffee, chat with co-workers about non-work things, etc.) but when you are home alone you don’t get those breaks. Be sure to get up, take a short walk or stretch, it’s good for both the body and the mind.”
    – Noel Seaton, Customer Enablement

    “This is probably only useful for me, but fridge visits are allowed just once in the morning and only to take fresh fruit.
    – Raul Arabaolaza, Software Engineer

    “WFH for 10 years – if I don’t get out (cycling) and see real humans (I don’t include family there – LOL!) I start to go a bit insane after about three days (e.g. during the rainy season). This is not great for the current crisis – I am pondering using Zwift and online cycling as a stopgap measure.”
    – Ben Walding, Director, Engineering Operations

    Additional Resources for Coping With COVID-19

  • The Software Agents: Lucidworks – Will Hayes, CEO – Remaking Retail Overnight

    The Software Agents: Lucidworks – Will Hayes, CEO – Remaking Retail Overnight

    The Software Agents – Episode 1: Lucidworks – Will Hayes, CEO – Remaking Retail Overnight

    The Software Agents is a new podcast series sponsored by CloudBees. Each week we bring you leaders from many fields applying software to reimagine them for the new world under construction.

    Our first guest this week is Will Hayes, CEO of Lucidworks. His company powers search for major retailers among others. Will tells us how in the months since lockdowns began, most brands’ online stores went from just one of many sales channels to their flagship presence. How does his company’s software let them bring their unique in-store experience and expertise to online customers? Will also talks a bit about his personal journey as one of the few Black CEOs in Silicon Valley.

    Announcer: Welcome to the Software Agents, a podcast series that brings you the people using software to help change the world in this time of transformation. With the help of some of the brightest technology minds, we’ll explore how almost every possible area of life, society, and business is being reimaged through the power of software.

    Christina Noren: Welcome to the first of many podcasts on how software is helping the world survive and evolve right now. I’m Christina Noren and my cohost is Paul Boutin. Hi, Paul.

    Paul Boutin: Thanks for tuning in.

    Christina Noren: This podcast is sponsored by CloudBees, leader in software delivery automation and software delivery management, with over 40 percent of the Fortune 500 relying on its leading continuous integration, continuous delivery, feature flagging and cloud-native products. What I’m excited about is today we have one of my favorite people as our first guest, Will Hayes.

    He’s the CEO of Lucidworks, and we’ll let him tell us a little bit about himself and we’ll get started there.

    Will Hayes: Great. Well, thank you. I’m very excited to be here. I’m Will Hayes, CEO of Lucidworks. Lucidworks, we provide a proprietary search engine that combines the power of search along with AI and machine learning to aid in providing personalized data experiences, recommendations, discovery, and we can apply this to areas such as retail.

    So customers such as Nordstrom Rack and REI, when you’re shopping online, and then even behind the firewall we power things from Morgan Stanley’s wealth management desk to a number of enterprise search and knowledge applications across the Global 2000.

    Christina Noren: So the reason, you know, we’re doing this podcast is to explore a little bit about the software stories behind the scenes of how the world is shifting rapidly. Like you have people talk about digital transformation accelerating, you know, 10 years – in a few months, these days. And, you know, so for me I’ve known you for a long time, Will, and I know what Lucidworks has done for a long time, and it seemed that the shift from retail to – I will use the stupid term – e-tail, you know, has been incredibly rapid and I can only imagine how that’s affected your customers.

    Will Hayes: Yeah, it’s significant. I mean, you know, obviously pre-COVID everybody recognized that you need to digitally transform or die.

    We’ve seen, you know, just massive disruption in the retail sector in terms of folks who just simply didn’t make it to consolidation through PE and otherwise, and so we were working with a number of the leading brands on just really accelerating those digital strategies, ensuring that they’re providing experiences that are comparable to what folks can get from places like Amazon or Walmart.

    Obviously, when COVID-19 hit it went from, you know, digital is yet another channel – and in fact, a really interesting metric that somebody shared is they think of their website like one of their stores in Union Square, and so it’s not that this is a whole other paradigm, this is yet another storefront. So imagine now that Union Square storefront went from doing, you know, 5 percent of revenue to 100 percent of revenue overnight. This is effectively what has happened with these online properties, and they simply just were not ready for it.

    And so not only do you have to worry about availability, can we handle the load, can we ensure that every customer is being served and transacted and we’re capturing that value, but how do we think about the experiences that they have? How do we meet the expectations that they’ve been conditioned to expect from other consumer experiences – Netflix, Amazon, Facebook and so forth? And so there’s been a whole lot of urgency and acceleration of getting to a point of not just being digitally transformed but really about sort of being a digital master, right? Where I can now really drive this portion of my business as my primary vehicle towards monetization.

    Christina Noren: So tell me a little bit more about Fusion as a platform, and if you can take me through a specific customer of – you know, naming’s not necessary, but a specific customer of why they became a customer pre-COVID and how they’ve evolved their use of Fusion post-COVID.

    Will Hayes: Yeah. So let’s focus on the digital commerce business and we can talk about the digital – what we call digital workplace a little bit separately, because the motivations there are different.

    But commerce, again, is something that we all can kind of understand because everybody shops online in one form or another, whether, you know, you do your once-a-year type of holiday shopping or you get groceries every single week, and so it’s becoming more and more pervasive in just kind of the way that we live. What we have been helping customers really achieve over the last couple years pre-COVID is how do I leverage technology, specifically things like machine learning, to serve a more personal experience for my customers?

    And when you think about what is a personal experience, there’s sort of three dimensions to creating a truly engaging personal experience. One of them is just findability. I know that I want something. I’m coming into Home Depot or Lowe’s and I know there’s a particular tool. Or even more abstract – I know that I’m trying to perform a task, I’m trying to demolish a bathroom. Well, if I walk into the store not only can I state that intention and somebody will guide me to it, but along the way they can give me some expertise and some information.

    They can provide recommendations. This is why we like going into a store. Typically there’s an expert that we can converse with. When those experiences need to be taken online, and we don’t want to just simply compete on price and convenience – because guess what? You’re going to lose. Amazon’s already got that game won. We need to start thinking about how we leverage technology to meet those expectations. So ensuring that as a customer comes in to look for something, can they find it?

    Are the results that they’re being presented with, are they relevant? Did they ask a question? Can we answer the question rather than just showing a bunch of blue links? So that’s sort of step one to that experience. Step two is discovery.

    How do we implement machine learning and AI to provide product recommendations, recommendations that understand your favorite color, recommendations that understand the propensity for high end versus low end, or recommendations that are simply just based on the fact that we have a bunch of inventory that we want to get rid of and we want to put those in front of somebody. Then the third dimension is merchandising.

    I am a domain expert. I understand activewear, I understand – REI is a large customer of ours, and so outdoor goods. You walk into an REI because if I want to go on my first hike or I want to go climb Mount Kilimanjaro, somebody can guide me through that experience. Well, the same folks at REI want to then merchandise things digitally, so as you’re looking for hiking boots maybe they know that you might want some poles. Maybe I’m going to use my expertise to recommend a certain style of pant given the temperature and given the type of boots that you’re looking for.

    So how an organization can use technology to bring product recommendations, personalized search experience, and then allow their domain experts to merchandise results is where we come in. Before us they were relying on either hiring the expertise that Google and Amazon and Facebook have internally, which is very difficult once you go east of the 101, or they were relying on very archaic sort of rule-based systems, things like Oracle Endeca that were very manual.

    Sometimes you have to create tens of thousands of rules to create that perfect experience. Obviously machine learning and AI, we can adapt and we can adjust based on the inputs and the signals that we’re seeing, and so that’s where our technology comes in and really empowers these customers to deliver on those three paradigm.

    Christina Noren: That’s fascinating. So after – you know, at the beginning of lockdowns, did you find that your retail customers we recalling you for different kind of consulting on how to apply this?

    And did you find that you were talking to a different audience within those companies?

    Will Hayes: So what was interesting for us, so every customer – sorry, every retailer typically they know when their peak season is going to occur. For a lot of them it’s pretty easy; it’s Black Friday, right? And so availability is important, being able to respond to trends with merchandising and promotions, all of that is critical.

    And so one of the things that we were well positioned for is dealing with abnormal spikes of traffic because we typically are focusing our sizing efforts around these sort of Black Friday types of events. What happened post shelter-in-place was almost across the board – I want to say every single one even though that sounds crazy, but I’m pretty sure it was every single one of our customers saw Black Friday-like spikes in traffic right away. This is kind of getting into like kind of the mid-February, and they sustained them for about the first three to four weeks of shelter-in-place.

    So not only did you have this sustained level of traffic but suddenly you had to start asking yourselves, what happens if this doesn’t change, if this is the new normal? And so a lot of what we were working with companies to do was to put their sort of Black Friday readiness in March, which is not something you would typically see. Now, you know, we have certain customers, a large grocery provider where Fourth of July is a big spike for them, right? One of our activewear customers, funny enough, January 1st.

    Right after New Year’s they get a big increase. So we’re all kind of conditioning for those events, but here we saw them in a far more unpredictable – and then another thing happened, by the way, and this is kind of crazy. Then the traffic went away. So you got this huge spike and this huge, sustained period, and then guess what? Everybody got a new bike and a new mixer and a new yoga mat and a new whatever it was that they needed to stay sane at home and then they kind of calmed down again. And so now companies were trying to figure out their post-sales motions.

    What do we need to do to continuously promote and provide services and maintenance and other things back to these customers on a cycle that’s not our typical cycle? Sorry, I think I cut you off.

    Christina Noren: That’s fine. I just have two questions there that are divergent. So my first question is does Lucidworks offer Fusion mostly as a SaaS or mostly is on-premise? And my second question is kind of, you know, search experience you were talking about earlier was – is that something that you’ve been trying to figure out how to deliver in an email or whatever kind of nurturing kind of form?

    Yeah. So I mean on the first question, SaaS versus on-prem, and this is one of the opportunities and challenges of the transition that we’re going through right now, which is we have primarily worked with very sensitive payloads of data with very calm technology-centric companies, and so what that means is even some of our retail companies or customers tend to operate more like technology companies.

    So very competent and very comfortable managing their own operations, they’ve got their own playbooks for SLAs, for RCAs, and we would plug right into that. When we’re dealing with banks and healthcare, obviously the data sensitivity, they would also want to run those on-prem. In the last year we’ve seen a shift where about 80 percent of our business is going towards SaaS of new business. About 20 percent of our on-prem customers are actively migrating and, you know, the other kind of 80 percent of legacy is sort of sticking with the on-prem model.

    So there is a bifurcation and it’s one that, you know, we have to think about constantly in terms of how do we build our org charts, how do we go to market, how do we provide support, because we’re starting to create these two very different constituencies of users. So that was the first question about SaaS – the second, excuse me, if you could just repeat it. [Laughs]

    Christina Noren: No, I was wondering about, like, you know, so you’re delivering search experiences, and what I know from working with you over the last few years is, you know, four or five years ago you guys were visionary in figuring out that it was about an experience, not about I’m typing in terms into a search box.

    And so, you know, as retailers like – you know, Neiman Marcus has been my experience with lockdown retail, and I’ve had this – and I was searching online and my saleslady there, you know, was trying to help me remotely because she was trying to keep her commission, so I was trying to keep her in business. [Laughs]

    You know, but the emails that Neiman’s is sending me – and you don’t have to disclose if they’re a customer – but the emails that they’re sending me, how much are they informed by search algorithms and what you’re doing?

    Will Hayes: Thank you. This is the golden opportunity, and so I’ll talk about what our vision is and then specifically to why the Neiman’s problem exists and why this exists in so many places.

    And so our vision goes well beyond search. We believe that every digital interaction needs to be better informed and better enriched, and so what I mean by that is if, you know, pre-COVID I said to you I need you in New York tomorrow, there’s probably about a half dozen screens and applications in which you’re going to go engage. Each one of those is an opportunity to be more productive, to know your seat, to know your time preference, to know which hotel based on your calendar. I mean you could think of a world in which all of the data is informing every engagement that you have. Now across channel that can be quite difficult.

    Across company or provider obviously nearly impossible. But within an individual branch, the fact that I cannot provide you that consistent experience from the time that you talk to an agent on the phone from the time that you go online to the time that you receive an email. What I often say to my customers is, “Look, you are treating me as if I am a different person depending on which channel that I show up on. Guess what? I don’t feel like a different person.” My engagement with Neiman Marcus doesn’t change based on the fact that I’m on the phone or I’m on an email or I’m on a mobile device.

    What changes is that the way that we’ve architected solutions has created these silos where now the application is like an instantiation of me in this silo, not an instantiation of me just an individual who happens to be showing up through a particular channel. So part of delivering our vision is that we are creating almost like a cloud in which we can inform interactions. An interaction might say Christina just ran a query; what color should I rank that query by based on her preference?

    I’m going to send an email to Christina. Which color should be in the email? A really simple example; but again, that one consistent thread that could tie that personal experience creates that level of engagement and trust, because most companies grow through acquisition – we acquired a mobile app company to go build our mobile experience, they’re creating a set of insights to go build a great mobile experience. Web marketing has been collecting insights about customers since the beginning of email, yet they’re doing it on their own. The website and the search team are doing it on their own.

    These insights end up getting siloed which creates this breakdown in experience. So over time we are solving the search problem that’s attached to revenue, but our vision is to help customers break down the insight silos across every channel that informs and touches the customer interactions.

    Paul Boutin: I know that people talk about an omnichannel experience, and right now the omnichannel is pretty much the one channel, which is the website, but I’m curious from an outside – from a demand side point of view.

    The two things I’ve – as you were speaking that came to my mind. The first is just the simple one of what else besides my favorite color and other proclivities might you know about me that I as a customer never realized?

    Will Hayes: Yeah, a lot. [Laughs] And I mean that. I mean what’s interesting – so let me give you an example of one of my favorite from a home improvement customer, and here’s something that they do which I think is so slick.

    So you show up and you start searching for a faucet because you need to replace a faucet. Maybe it’s broken, maybe you don’t like the color or whatever. Okay, so we’re going to help you find the best faucet. We might rank it based on whether there’s a certain finish that we know you like, we might rank it based on your propensity to buy high-end appliances versus low-end.

    But what they’re doing is we’re creating what’s called a customer data profile. The next thing you do, you look for a shower curtain. Okay, maybe I serve you a shower curtain. Next you want a toilet seat. Time out. We can interpret that now – you have an entirely different intention.

    You went from replacing a couple things in your bathroom to doing a remodel. I can completely change the experience now. Let’s get away from just serving you up a catalogue list of faucets and toilet seats; let’s start talking about projects. Oh by the way, have you seen what we have over here in the pro section and do you see the services that we can have to go offer? So that’s step one, intersection that to map you not only to a certain preference but to a certain intention that you might have.

    The same customer now you’ve come back two or three times to the site and you either have this obsession with remodeling your bathroom or maybe you’re a contractor. An entirely different experience is going to be presented back to you. So it’s not just like tracking kind of the more personal stuff – do you like this or do you like that? – it’s the brand trying to understand you, because they have their own domain knowledge. They can spot a DIY bathroom remodeler just from the way they walk up and down the aisle.

    How they do that digitally and craft that experience digitally, that’s what will keep you going back to this particular customer and not just buying the stuff for cheaper on Amazon.

    Christina Noren: So Will, let’s bring that back to the current moment. This is really profound for me, which is basically, you know, what are associates trying to do inside of stores that they can’t do during lockdown and depending on how long lockdown is going to happen?

    But coming back to your customers right now, how have you had to help your customers deal with this adjustment where you don’t know if it’s, you know, four weeks and then, you know, four weeks of they are done buying their Pelotons and yada, yada, and now we’re thinking about like what does four years like this look like?

    Will Hayes: Yes, yes. And it’s funny because it’s four weeks of buying followed by a month of support and getting it set up then quiet, right? [Laughs] And so a really good example of where we’ve had to step in –– and in fact, we accelerated our roadmap based on this, is call centers, and so we’ve been working on a feature which we call Smart Answers, and the premise of this feature is that we can process lots and lots of content and try to detect question and answer pairings out of it, very similar to if you ask a question to Google you’ll notice that it will pull answers out of Wikipedia. It’s training on Wikipedia to answer questions about people or places, events, and so forth.

    Well, you know, within the corporate – or the – yeah, the corporate corpus of information there is a massive amount of knowledge, there’s a massive amount of answers, but corporations obviously can’t use Google to train on top of their proprietary data. So we built a system to help train question and answer pairs out of massive amounts of content. This was something we were actually going to release later in the fall. One of the things that happened as a result of COVID, and this was really interesting – I don’t know if people fully get this – obviously while your customer service call centers are being massively overrun, or so it seems –– call times are longer, I’m being directed to the website, they want to call me back, whether it’s your credit card, your airline, you name it. Now in the case of –

    Christina Noren: Don’t get me into the two weeks of trying to _____ lobby enterprise. [Laughs]

    Will Hayes: But here’s the key, here’s what people don’t understand; it’s actually not the volume. The problem is getting people equipped at home to take calls. You have the problem of equipment – I need special software, I need special hardware – you also –

    You know, a lot of times the people who come in and work at call centers, these are a very transient workforce, so you typically have people who don’t stay in their jobs for very long, they rotate very highly, and so typically in those situations more supervision is required so it’s harder to have people working remote. So it’s not that we’re necessarily getting inundated with call volume. What’s happening is companies simply cannot service call centers remotely and it’s causing a huge headache.

    So one of the things we did is we accelerated the release of smart answers because really the core value prop here is call deflection, helping your customers get answers faster and resolve issues on their own using this question and answering technology, and so that’s something that, you know, our customers pushed us to release based on the fact that they’re having this bottleneck with their call centers just not being equipped for remote work.

    Christina Noren: So let’s shift gears a little bit. So you have been in the news recently as one of the few African American CEOs of a Silicon Valley 20:59 company.

    So, you know, would love to understand a little bit about how recent events have affected you personally and, you know, you were dealing with a first wave of COVID and lockdowns in your professional life and then there’s been this surge in issues that probably affect you on a personal level.

    Will Hayes: Yeah. I mean [laughs] you kind of summed it up.

    You know, the current wave, I mean to what you said earlier, which was, you know, we were all dealing with this sort of unprecedented amount of just adversity in our businesses no matter who you were. This is just – it’s hard to scale, it’s hard to make decisions, it’s hard to not feel overly reactive when there’s just so much uncertainty. You just don’t know. Are we going to be closed in lockdown for a month, for a year? Will the economy bounce back in Q3 or in 2021? So obviously that created a lot of just angst, and as leaders of organizations just a lot of feeling like you’re sort of grasping in the dark at times.

    But, you know, collectively as an industry I mean everybody’s sort of going through this together, so that’s always a nice equalizer in terms of dealing with issues. When you bring some of the social issues that came on top of that, I think there’s sort of two things that come up. I mean one, it’s just more stress for your team. So we worry now about people’s personal safety, we worry about, you know, the situations in the communities that they’re in and that’s just us ensuring that we’re providing as much support as possible for our companies.

    I think for myself, you know, being a black leader, there was this added, I’ll call it just sort of burden of now, you know, what are you going to say or do about this thing that has affected you your whole life but is suddenly very topical [laughs] and people want statements and they want you to express your feelings, either as an organizational leader in terms of what we’re doing for the company or as a black leader.

    And, you know, to be honest, the burden kind of just pissed me off at first because it’s frankly just more stuff to deal with. You know, in the end, what I got both comfortable with and convicted behind was, one, I’m just going to tell my own experiences, because that’s the best thing that I can do. I have experiences growing up with police, I have experiences in just being in the Bay Area and being in tech, and I’m not here to cast those experiences as being negative or anything. I mean I’m here where I am today as a result of everything that I’ve experienced.

    But I will share the story, because people seem to be listening to the story. And then number two, what I recognized was that having gotten to the point that I’m at is a privilege and I can use that privilege to either just keep my head down and continue doing what I’m doing and hope nobody takes notice and kind of leaves me alone, or again, I can use it as a platform to share. Because being somebody who’s successfully raised money, who has more or less successfully navigated the Valley, I felt that it was important for people to know that I still deal with this crap.

    And it’s discouraging and it’s frustrating, and even though I was able to kind of push through it there’s plenty of people who would not and there are some simple things that could be done, like looking up who the CEO is on LinkedIn prior to a meeting, that would significantly reduce the burden that founders and CEOs, particularly black founders, feel in this entire game. And so that’s where I just got comfortable where, okay, if my – the mark that I can leave on the world is just that I’m more than happy to participate in the conversation.

    Christina Noren: [Laughs] I’m laughing because that’s the same thing I’ve been saying about the experience of being a female CEO raising money in the Valley with experience. It’s like, literally, you know, I’ve been asked if I had worked for people that I had hired in their first job.

    Will Hayes: Oh, yeah. There you go. And this was clear when my article came out of many women leaders were sharing very similar experiences. I mean it’s so maddening again because it’s such an easy opportunity to get it right.

    You don’t have to do a whole lot. It doesn’t cost you anything to do that right. And the impact and the cost of getting it wrong is significant and people recognize that, but then here in lies the catch; now you realize you made a mistake, now you’re even more uncomfortable, which means your ability as a female CEO, as a black CEO to go out and raise money has been severely handicapped, and that’s a problem.

    Christina Noren: Yeah. Well, I think that’s true.

    So I think it would be helpful for our listeners to hear about your personal journey. You know, so where did you start from and how did you end up CEO of Lucidworks? And tell us a little bit about the scope of Lucidworks as a company right now, you know, size, funding, yada, yada.

    Will Hayes: I met you in 2005 and the rest was history.

    Christina Noren: Not true, because you came – I’m going to lead the witness, because you came in as a group of the young engineers that really created Splunk.

    That’s a very understood part of Splunk’s history.

    Will Hayes: Sure. No, I appreciate that for sure. You know, like my background, and I think this is also why the conversation around race and everything else gets more complicated, at least in my perspective, just because I don’t fit any mold that you’d probably consider to be in this role or doing kind of what I’m doing now. I grew up in the Bay Area. Dabbled in college.

    Didn’t really find any success there, but had always been just a lover of all things technical and so was very fortunate – I had a computer in my house growing up, which was very rare. I even had internet, like going back to the ’80s, and so I had a lot of exposure to things like BBS and IRC, and I remember just the infatuation I had with connectivity, like the fact that I was talking to people all over the world. I thought it was just fascinating. Then when I learned that the internet was not only this really cool vehicle for connecting and having fun but I could manipulate it, meaning I could write applications, I could build stuff, just completed fascinated me.

    I was always an entrepreneur by heart, starting businesses from mowing lawns to babysitting to just anything I could think of to go make money, and all of a sudden I just unlocked this world where I could build and I could build anything to my heart’s desire and I could build applications and I could build things for companies. And so as a teenager I was actually making – earning money just doing a lot of technical things. Again, this was the ’90s. I just want to be clear. Like today it’s pretty hip to be into tech and coding and all these things when you’re young.

    Back then this was not ever heard of. [Laughs] In fact, we were – me and a couple other guys in my school who ended up at Splunk as well, we’re all very quiet about our passion for technology, risking get our butts kicked literally. And so –

    Christina Noren: _____ much more into Trans-Ams than tech.

    Will Hayes: You got it. Yeah, you know exactly who I’m talking about. So fast forward and, you know, I had built a couple different apps, and again, just kind of got a real feel for tech and what I wanted to be and what I wanted to do.

    I ended up with an opportunity out of high school to go intern at Genentech which then turned into a contracting job when I was going to go back to school, and then when school didn’t work out it very quickly became a full-time offer. So I was very fortunate that as the real hype of the first bubble was occurring it would’ve been really easy for me to get consumed by that and potentially just spit out the other side, and instead I landed somewhere that was incredibly supportive, just had a very rich culture, and allowed for kind of an awkward 18-year-old to kind of figure himself out in this sort of corporate setting that frankly I had very little to no exposure to prior to that.

    So I worked at Genentech for about six years, and got a call from a friend of mine who said, “You know, we’re hiring a QA engineer,” and I think I was like – at that time I was about 24, and I remember my – the calculus that I did in my head to see if this was a good career opportunity was, one, was it in the city, because I was driving to South City in a car that I hated that was like literally dying on the side of the road every other month –

    – and then two, they had an Xbox, which I just thought was like – well you can’t have a software company without a video game console. And so that’s what led me to Splunk and meeting you and the team and, you know, I think I was somewhere in that first sort of 12 to 15-ish employees and, you know, we were turning over a few at the time. Not a lot of people in engineering. One of the things that was really prevalent to me when I go to Splunk was I was in QA, so I was hired in kind of the most junior engineering role that you could possibly be hired in.

    But I had come from a highly-regulated, process-oriented industry – biotech. And so the big contrast to me coming into this startup was just there was no process, and I remember working with you and even Paul at the time actually about just how we can figure out what needs to be tested for a release, what needs to be documented, and kind of started putting some of that more program management behind engineering, and that had quickly sort of evolved into being kind of a program manager for engineering.

    I’m sorry. You were going to say something?

    Christina Noren: I was just saying something, because we lost all of the state department’s firewall logs for three years at that time.

    Will Hayes: Right.

    [Laughter]

    There was quite a bit that was going on, yeah, that the lack of process showed, but we were building the right thing, which is what matters most, kids. And so, you know, in that experience I got to go from working in engineering, work really closely with you and the team, and then I went into the field where I got to be an SE for Biz Dev, which was really fun.

    Because, you know, you got the experience of being in sales and understanding how that worked, but at least BD I felt – it allowed me to be very entrepreneurial still. We were thinking about solutions and new markets and building things, so it never felt like I was just in that rinse, wash, repeat cycle that a lot of sales engineering gets into. That I felt like really kind of rounded me out, and so it was a great experience and obviously we scaled that through IPO. And then, you know, frankly I mean you could tell the rest of this story, you called me and you told me about this company that was sort of going through some growing pains and trying to figure out its identity.

    And luckily, I was pretty naïve as to like how much work it would take to turn around a company, [laughs] so I was like, well, Christina thinks I can do the job and I have this idea of what I would go build, so I’m just going to go join this little struggling startup and how hard can it be? And lo and behold it turns that, you know, any pivot, whether the company’s sitting at $2 million in revenue or $20 million in revenue is incredibly difficult and it requires a lot of conviction from the organization as a whole.

    And we could spend a whole podcast talking about turnarounds but, you know, I’ll close in summary to say that I think the combination of having a very deep technical background when I was young, especially since I didn’t have a formal education, you couple that with the just perfect marriage of a young company that’s about to explode, you know, great mentorship from people like yourself – and I mean that from the bottom of my heart – it was one of these things that just set me up so perfectly that when Lucidworks needed a leader you couldn’t have really crafted I think a better job for me.

    And I say this humbly just as if like it’s a coincidence. It was very, very easy for these two things not to line up. But just given the Splunk experience, given that they were sort of need for more kind of a technical founder foundation, it created an opportunity for someone like myself with little operational experience to come in and be a CEO, and seven years later here we are. [Laughs]

    Paul Boutin: Here’s my question. What is the short, 15-second radio answer of the one thing that when you became CEO you realized this is a totally new thing that I have to be good at besides everything else I’ve got?

    Will Hayes: I’ll tell you, it’s funny because I was telling somebody recently; the way people relate to you. I’m a very kind of social person. I feel like I get along with people, I’m very empathic. It’s just kind of myself. Like I just – I love people. I find people fascinating.

    And so I like to engage with people very closely. What I learned was that those organic sort of engagements between me and call it an employee were not always between Will and an individual. They were this person and the CEO, and agendas turn on and whether they know it or not they’re kind of somewhat manipulative, and that was hard. Because again, I just wanted to be – you know, I’m just like everybody else, because frankly I am, but the role carries a certain just context in which people react to regardless of how hard you try to just connect with somebody on a personal level.

    Paul Boutin: That’s the premise of The Office sitcom, is that the guy wants to be a pal when what they need is a boss.

    Will Hayes: They need a boss. Right. Yeah, yeah. [Laughs]

    Paul Boutin: And it causes them to not respect him. One more thing I wanted to bring up per our previous topic, and I just want to hear about your experience. I am well aware and have dealt with people…I don’t even want to talk about it.

    That as a black CEO with a substantial revenue under your belt right now and success in six years, I’m sure you’ve dealt with people who think you’re a figurehead. Oh, you’re not really the CEO. And what – how do you – I’m thinking in terms of people who hopefully will find themselves in your seat and therefore will have to – what will they have to deal with that you’ve had to deal with?

    Will Hayes: Yeah. I mean first it’s one of these jobs where I think everybody’s got a better opinion, right, on how to handle it.

    In fact, I made the statement to the company the other day. I said, “Look, like one of the things I’ve also had to accept in my role is that I will never be given the opportunity to make a unanimously popular decision.” Like, never. Because no matter what I do there’s always going to be somebody that it was just – it went against their agenda. In fact, it was funny; what I thought to be the most popular thing I ever did was during – when shelter-in-place first started and it was just a very intense time and everybody was just kind of trying to figure out life, you know, we granted what we called mental health days.

    And we gave a long, four-day weekend and said, “Look, no PTO. Nothing. Just go get your stuff in order.” Like everybody’s just got a lot on their mind and, you know, here I thought like, oh, what a great leader I am just offering these free days. No, of course like the sales team started complaining to me about meetings and how SEs don’t want to show up and this and that. So I bring it up just jokingly but the truth is that you’re never able to make a popular decision in this capacity and you just sort of have to accept that, right?

    That if they were easy decisions to be made they’d probably be made before I got involved. [Laughs] I’m getting involved because frankly the answer’s gonna suck one way or the other and somebody’s got to be accountable for that.

    Christina Noren: You’re right. We’ve hit a little bit on the issues of how your customers are changing their demand for your products in response to this. We’ve hit a little bit less on the issues of how, you know, you just barely touched in answering Paul’s last question on how you’ve had to deal with changing your work patterns within the organization.

    And then we’ve also, you know, hit on the issues of how your personal story has led you to this current point and it slight affects, you know, how people deal with your decisions.

    Will Hayes: You’re definitely grabbing them all, and I will – just to kind of put some more color on Paul’s question of sort of the perception that people have, you know, it’s amazing – and I’ll share this. And it’s not – it doesn’t feel good, but it does happen.

    There’s been cases, particularly with senior employees – so folks call it director, VPs and above – where they seem to still not fully grasp the fact that I’m in charge. [Laughs] And I mean that just – and again this is where unconscious bias is so interesting, because these are people that I think I have great working relationships and we have mutual respect, but what they don’t necessarily recognize is, you know, often going to the COO for maybe permission for something or organizational changes or –

    It just shows up in these very subtle ways. I’ve even had cases of, you know, employees frankly trying to confront me around strategic decisions, which is always interesting because I welcome that level of debate any time, any day, but just the way in which people do it and you can sense this sense of like, oh wait, you actually feel like [laughs] you’re going to be right here regardless, you know?

    And so that’s where, again, unconscious bias, it plays in, even in the cases where frankly it can be career-limiting for folks. They sometimes don’t have an ability to either catch it or measure it, so just something worth thinking about.

    Will Hayes: Yeah. I mean I’ve experienced that as a woman leader, and I can only imagine how it is, you know, with a much more deep – you know, it’s like a developed _____ bias, you know, where –

    Will Hayes: Yeah, I mean I think it – again, everybody has their experiences, but I think the concept of structural bias, we all know what we’re talking – like we’ve all experienced that thing even though it shows up differently.

    And frankly, you know, I think this is – we’re talking about it now at the more specific, abstract level than whether or not somebody’s a sexist or a racist, because that’s not the issue in my mind that we’re here to discuss. We’re here to discuss about, you know, how do we get leverage across all walks of life here to build better businesses? And frankly, we are missing that because of some of this institutional bias that’s embedded in the way we operate. It’s just bad business, first and foremost.

    I can talk about socially why it bugs me, but frankly just, you know, as an entrepreneur, as a capitalist, we could do better here and this is the opportunity. So I’m hopeful, but I’m cautiously optimistic.

    Christina Noren: Well I mean it seems like we can emotionally sense when we’re dealing with somebody who is not coming from that place, and I feel frankly, Will, like this is part of your and my bond over the years, even though we’ve often been set on politicized opposites.

    [Laughter]

    You know, so – but I feel like we can sense that we’re coming at this from a place of who is this person, what do they have to offer intellectually and emotionally and not from whatever background they come from.

    Will Hayes: Absolutely.

    Christina Noren: And I hope this moment actually brings – you know, brings us to more of that.

    Will Hayes: I could not agree more. No, I could not state it better. And again, hope is the term that I’ve bene using a lot lately. I’m encouraged, but I’m not naïve. [Laughs]

    Christina Noren: This is close to the end of our time together. [Laughs] So Paul, what was your biggest take out of this?

    Paul Boutin: That retail is one area that everyone understands that applies to what we’ll be talking about every week, that there are many areas that people don’t think of as being based on software, reliant on software, or being totally remade for their own benefit, for people’s benefit, by software.

    And yet here we are, because what used to be, oh yeah, we have a website has suddenly become that’s what we have. And yet behind that isn’t just uptime and reliability and scaling; it is really taking what makes a retail store something you love to go to – why do I love going to Ralph’s instead of the other supermarket – and bringing that into an online, on-the-phone experience in a way –

    And maybe – and this is my last question. It’ll be really quick, just yes or no. Are some of your customers coming to the decision or thinking about deciding that what used to be their differentiator and brand bond in the brick and mortar world is not going to be what makes them special online?

    Will Hayes: Yes, every single one.

    And it’s terrifying, but if they can look at it with the right lens it should be an exciting opportunity, but there is no question across the board that if you’re competitive advantage was that in-person experience, you’re going to have to transform that rather rapidly. Carrying forward, what makes Ralph’s special, what makes REI special, what makes Best Buy special? The blue shirts, the experts, the way the merchandise is laid out on the shelf; all of that expertise and knowhow is still valid. It just needs to be applied now digitally.

    And if not, I think we know what happens.

    Paul Boutin: And is it possible there’s something else that isn’t any of those things that might bring in and say, “We have this and we see that Amazon doesn’t so people will come to us”?

    Will Hayes: Experts. Depth. It always comes down to depth. One of my favorite stories from a fashion apparel retailer here in the Bay Area actually was the difference between us and Amazon is Amazon has no taste.

    Paul Boutin: [Laughs]

    Will Hayes: And so, you know, Amazon’s going to recommend you whatever the machine recommends. That’s machine learning, ladies and gentlemen.

    For the rest of us it’s – this particular company said, “Look, we set the style for the summer. You want to buy that shirt with those pants? I don’t care if 99 out of 100 customers buy that shirt with those pants, if we don’t determine that those two things go together we will never merchandise them, we will never recommend them.” So the difference is, you know, Amazon, you’re shopping for a lawnmower and you keep getting running shoes recommended to you, right? Because Amazon just – like again, they’re just a movement machine. Other brands are really about creating an experience, right? Creating a sense of trust.

    And that’s not by me just jamming stuff down your face. It’s about curating those experiences.

    Paul Boutin: And I’ll throw in one last thing, that I have been in the store where the clerk, who’s not one of REI’s experts, says, “Oh, everybody’s buying these,” and doesn’t realize that’s the last thing you want to tell some people.

    Will Hayes: Oh god, yeah. There you go. Thank you. [Laughs] Right. Yeah, exactly. No. Yeah. Guide me towards that thing that feels specific for me. My wife will tell you – I’m a sucker for that. I can be upsold anything.

    Because the moment you tell me, “Oh wait, I gotta show you this thing,” you and I have a trust going that makes me a sucker. Anyway…[laughs]

    Christina Noren: Well, I have a lot more on that but I’m not going to take more time because we’re out of time, and that was a really good return to, you know, what’s changing. So a little bit of an insight into how maybe software’s not changing the world during this time but maybe software’s enabling the changes that are happening.

    Will Hayes: Oh, yeah. No question.

    Christina Noren: Thanks, Will. Thanks, Paul. And we’ll look forward to another episode of –

    Will Hayes: I had fun. I hope I get to come back after the inaugural wave gets aired here. But thanks for having me. This was a ton of fun.

    Paul Boutin: Thank you so much, Will.

  • The Software Agents – Episode 2: Art Museums Get Smart

    The Software Agents – Episode 2: Art Museums Get Smart

    The Software Agents is a new podcast series sponsored by CloudBees. Each week we bring you leaders from many fields applying software to reimagine them for the new world under construction. Listen to the second episode here.

    Our guest this week on The Software Agents is Rich Cherry, managing partner at Museum Operations, a consulting agency. He’s also co-chair of the MuseWeb conferences. Rich has been a leader in museum IT for two decades at such storied institutions as the Guggenheim and the Albright Knox Gallery. He is widely credited with having managed the entire construction, launch and operations design for The Broad Museum in Los Angeles in recent years.

    In this podcast, we ask Rich to tell us about the journey that a computer-tinkering kid took through systems support in the Marines, and IT jobs in banking, to the arcane world of art museums. He takes us into the inner workings of nonprofit museums, where the context and goals for software and technology are very different from those at for-profit attractions.

    Rich describes the groundbreaking software systems that he and his team built at The Broad. These enabled The Broad to serve some of the biggest crowds in L.A. in the two years since its launch, despite the challenges of working in an unusual physical space with a smaller-than-usual staff.

    We explore how the flexibility and power of these software systems will help The Broad and other institutions around the world meet the challenges of re-opening to the public.

    Rich also muses on the possibilities for completely new digital experiences for museum exhibits and collections. Just as shopping online misses much of the in-store experience, looking at digital images of artwork misses aspects of a museum trip that we might not have noticed.

    Both live and digital museum experiences are evolving, even as museums wait to reopen. Thanks to software, they may actually be better.

    Rich Cherry Headshot
    Museum Operations Logo
  • Fidelity drives Software Delivery Performance

    Fidelity drives Software Delivery Performance

    The following blog post is based on a presentation at CloudBees Connect. The full recorded session is available below.

    Wistia video thumbnail

    Few industries depend on software more than financial services. Jimmy McNamara, software engineering product manager at Fidelity, should know: He’s worked in the industry as a software developer and project manager for over two decades, most recently for Fidelity Investments, one of the largest investment firms in the world. Fidelity’s brokerage business alone manages multiple trillions of dollars for clients worldwide.

    With so much value at stake, McNamara says that Fidelity can’t afford to let its software products lag behind the industry. It’s why the company keeps more than 10,000 developers busy building and maintaining a broad range of business and customer applications. “Fidelity is a huge believer in IT,” he says. “It’s part of our core philosophy and business strategy. It’s something that’s constantly discussed at the highest levels in the company.”

    How great software is produced at Fidelity Investments

    McNamara’s job is to help Fidelity’s developers produce great software as fast as possible, but also as safely and securely as possible. Doing so requires him to strike a balance between enforcing security through a central platform and allowing developers to use the very best tools available. “Governance and security are non-negotiable,” he says. “But at the same time, we don’t want to get in the way of our developers if they want to leverage the latest technology.”

    To gain access to best-in-class development tools, Fidelity increasingly looks to the cloud. “There’s a huge number of new features and a ton of automation that can be achieved by operating in the cloud,” he says. “It’s a game-changer in terms of the ability to improve operational outcomes, realize market opportunities and grow the business.”

    To shift the balance toward cloud over time, McNamara prefers to pull rather than push the dev teams. “We establish new capabilities and we make sure those capabilities are better than before, so our developers are naturally drawn to them,” McNamara says. Almost always, developers find the cloud environments easier to use and more conducive to innovation. “Ideally they don’t need to worry about set up,” McNamara says. “They can just focus on innovation and writing code, and it’s a better experience than before.”

    Driven by data

    To stay on track, McNamara’s team is constantly measuring how well its evolving platform is performing and delivering value to the business. “We’re very focused on data,” McNamara says. “If you follow the data, you can get to where you need to go faster.” The team tracks a range of performance metrics, such as mean-time-to-recovery (MTTR) and how quickly they are providing the features that the business requests.

    The data helps his group prioritize new platform-improvement projects and spot trends early to get a jump on emerging problems. For example, his team may decide to add automation features ahead of time to prevent an issue from impacting the business. Moreover, having access to reliable data drives more fruitful discussions with stakeholders about the value of the group’s services. “It moves the discussion beyond opinion to a more accurate, value-based discussion that really drives our services roadmap,” McNamara says.

    In the past few years, the company’s embrace of cloud-based platforms has yielded tangible improvements, such as better operational resiliency, much of it driven by the cloud’s inherent elasticity.

    What’s more, the move has given developers a richer environment in which to learn and grow. “It’s great to see a team move to cloud-based platforms,” McNamara says. “You can witness the transformation of their skill set. Their whole role in the organization changes because of the new features available in the cloud. In the end, your developers are happier because they get access to more scale, more automation, and more features. Not only that, but their skills become more marketable.” McNamara also knows that having the best tools is key to recruiting and keeping top talent.

    To ensure a successful transition, McNamara suggests hiring engineers who are naturally curious and eager to embrace new things. “The key is to bring on really inquisitive people,” he says. “It’s all about people as far as I’m concerned.”

    For those who might be reluctant to give up on their traditional on-premise environments, McNamara suggests leading by example. “If you’re a central team or service like us, you should get your stuff out first. Show it off. Demonstrate how you’ve achieved the outcomes you’ve delivered.”

  • Testing with Feature Flags to Improve Developers Productivity

    Testing with Feature Flags to Improve Developers Productivity

    Feature Flags can improve your continuous integration process in a number of ways. This post will focus on how CloudBees Feature Flags can help improve your developer productivity and shorten the feedback loop with the Flag Override view for frontend validation.  It includes Javascript in examples, but the override view can be used in all available platforms.

    The flag override view is a lightweight UI element that is very useful for debugging purposes. This override view exposes the current status for each flag set by developers and allows users to override these flags. All this is accomplished from within a handy popup in the UI of your local development instance or other instances used for quality assurance or user acceptance testing.

    For organizations, this view improves developer productivity by enabling them to rapidly validate the functionality of their newest code additions in your local environment frontend. To get started, first import the CloudBees Feature Flags SDK to your application:

    import Rox from 'rox-browser';

    Then, you will want to add the flag override view to your code. For example, this line adds the override view and controls where to display the view:

    <button className="btn btn-flags" onClick={() => Rox.showOverrides('bottom left')}>Flags View</button> 

    Check out the Browser side Javascript API for a full list of parameters.

    Once you have the override view in your local environment, you can toggle any and all frontend flags in your code to validate various code blocks and how they interact together.

    Now you can merge your work back to the master branch faster AND with more confidence!

    Shorten Feedback Loops with Feature Flags

    Quality assurance team(s) without access to the flag override view are typically stuck chasing each feature developer and waiting for them to modify code anytime QA needs to compare new and old functionality. This feedback loop could take hours if the developer is busy or days if the developer is on vacation, not to mention put a damper on developer productivity. With CloudBees Feature Flags and the flag override view, QA can shorten the feedback cycle by having complete freedom to toggle flags in their environment with the click of a button. There is no need to rope in developers to modify code, rebuild, and deploy just to update a flag. Now QA is empowered to work independently, without asking developers to break their focus or wasting precious business cycles.

    In conclusion, the flag override view is a handy screen designed for use in local and testing instances of your application frontend. The view helps developers rapidly prototype new functionality so they can get it merged to the mainline codebase faster. The view also helps QA folks work more independently of developer input and with more control of their experimentation all within a shorter feedback loop. Try the flag override view today!

    image1

  • Technical Debt Management with Feature Flags: Strategy & Best Practices

    Technical Debt Management with Feature Flags: Strategy & Best Practices

    Technical debt is accumulated as unmanaged flags accrue in an application’s code. And the associated marginal gain (i.e. each unmanaged flag added) directly impacts the amount of time and resources needed for testing. This can lead to more serious issues with the affected development, performance/testing and product processes becoming more expensive.

    As software teams grow and become more agile, it’s important to ensure a feature flag solution can scale. But it’s imperative that best practices and techniques are followed to avoid the technical debt accumulated by poor flag lifecycle strategy. This post will cover best practices for avoiding technical debt management when using feature flags.

    Strategic feature flag planning to avoid technical debt

    Sometimes, an ad hoc fix is necessary that can easily be resolved through an additional feature flag. All too often though, scenarios come up where teams feel pressured with time or resource constraints and resort to implementing feature flag gated code without a second thought. While this is somewhat of a normal byproduct of software development, planning is essential and a fundamental precursor to long-term success with feature flags.

    The time taken to plan prior to implementation assists in feature flag due diligence. Teams should ask themselves:

    • What will the flag be used for?
    • What team will use the flag?
    • How long will the flag be in use?

    The questions were listed in descending order. It’s important to realize this as each question helps filter flags, with the first dividing flags based on its high-level use and the last providing more granular detailed information. This preparation is critical to avoid the hassle of technical debt management later.

    How to Name Feature Flags to Avoid Technical Debt

    With these questions answered we can now begin naming flags. Companies have style guidelines for writing code, and should append these with its use of feature flags. Before creating a flag, cement the naming convention to be used; this will standardize the practice and help onboard future employees. Like variables, flag names are best left at the intersection of descriptive and terse (i.e. short and sweet).

    Some feature flag management solutions provide a namespace. This is the first funnel or way to search flags later on. A namespace should be used to identify how a flag will be used. For example, a set of flags should be defined to the namespace “releaseFlags” allowing for a separate group of “abTestFlags.”

    Once a flag has been created with a namespace, a label can denote which teams are using a flag. Since multiple labels can be applied in a flag management UI, it allows multiple teams to associate themselves with each flag.

    The description of a created flag provides verbose details, like flag creation date, or necessary information related to a dependency on another flag. This information is the last and most granular bit of the flag’s information.

    Best Practices in Flag Lifecycle Management 

    Review flags often. Flag management solutions can display and filter which flags are on, off or experiencing no traffic through an interface. But teams must be vigilant about removing flags and have a well-defined clean up process.

    Integration with tools like JIRA can help monitor and associate a ticket with the lifespan of each flag. Once a notification is sent that the flag is to be removed (e.g. the A/B test has finished, canary deployment was successful, etc.), the ensuing removal process is easily outlined from previously established naming conventions.

    After reviewing a flag’s description, dependencies can be noted and dealt with accordingly. we can review dependencies on all other associated flags. Referring back to the labels will delegate work as the responsible team will be notified to remove the flag from the code base.

    And where in the code should they look? Developers turn to the flag’s namespace, although it may exist across multiple tech stacks defined within an application. This is where an additional dashboard should be leveraged, specifically one that displays the environments and code languages a flag has been used in. With all of this information in place, it’s fairly easy to notify the responsible party and search within an IDE for all instances of the flag.

    Summary

    Naming conventions are the next most important element in feature flag management. Using an inverted pyramid mechanism helps define and sort flags from its highest tier of grouped buckets (i.e. type of flag) to its lowest where detailed information is defined.

    Managing flags throughout their lifecycles avoids the incurred technical debt they create. By constantly monitoring flag usage, teams can establish hard deadlines to clean up flags in code. Technical debt management – and the cleanup process – is simplified by sorting through knowledge communicated in naming conventions (in reverse order they were performed).

    These processes should be defined by a strategic feature flag plan, set up to avoid flags’ technical debt. If followed diligently, teams can leverage the unrealized gains to drive product innovation and ensure processes will scale.

  • How to Disable Code

    How to Disable Code

    The following is a guest post written by Carlos Schults.

    Being able to disable code in production is a power that many developers aren’t aware of. And that’s a shame. The ability to switch off some portions—or even complete features—of the codebase can dramatically improve the software development process by allowing best practices that can shorten feedback cycles and increase the overall quality.

    So, that’s what this post will cover: the mechanisms you can use to perform this switching off, why they’re useful and how to get started. Let’s dig in.

    Why Would You Want to Disable Code?

    Before we take a deep dive into feature flags, explaining what they are and how they’re implemented, you might be asking: Why would people want to switch off some parts of their codebase? What’s the benefit of doing that?

    To answer these questions, we need to go back in time to take a look at how software was developed a couple of decades ago. Time for a history lesson!

    Production Switch2

    The Dark Ages: Integration Hell

    Historically, integration has been one of the toughest challenges for teams trying to develop software together.

    Picture several teams inside an organization, working separately for several months, each one developing its own feature. While the teams were working in complete isolation, their versions of the application were evolving in different directions. Now they need to converge again into a single, non conflicting version. This is a Herculean task.

    That’s what “integration hell” means: the struggle to merge versions of the same application that have been allowed to diverge for too long.

    Enter the Solution: Continuous Integration

    “If it hurts, do it more often.” What this saying means is that there are problems we postpone solving because doing so is hard. What you often find with these kinds of problems is that solving them more frequently, before they accumulate, is way less painful—or even trivial.

    So, how can you make integrations less painful? Integrate more often.

    That’s continuous integration (CI) in a nutshell: Have your developers integrate their work with a public shared repository, at the very least once a day. Have a server trigger a build and run the automated test suite every time someone integrates their work. That way, if there are problems, they’re exposed sooner rather than later.

    How to switch

    How to Handle Partially Completed Features

    One challenge that many teams struggle with in CI is how to deal with features that aren’t complete. If developers are merging their code to the mainline, that means that any developments that take more than one day to complete will have to be split into several parts.

    How can you avoid the customer accessing unfinished functionality? There are some trivial scenarios with similarly trivial solutions, but harder scenarios call for a different approach: the ability to switch off a part of the code completely.

    Feature Flags to the Rescue

    Defining Feature Flags

    There are many names for the mechanisms that allow developers to switch a portion of their code off and on. Some call them “feature toggles” or “kill switches.” But “feature flags” is the most popular name, so that’s what we’ll use for the remainder of this post. So, what are feature flags?

    Put simply, feature flags are techniques that allow teams to change the behavior of an application without modifying the code. In general, flags are used to prevent users from accessing and using the changes introduced by some piece of code, because they’re not adequate for production yet for a number of reasons.

    Disable Code: What Are the Use Cases?

    We’ll now cover some of the most common use cases for disabling code in production.

    Switching Off Unfinished Features

    As you’ve seen, one of the main use cases for feature flags is preventing users from accessing features that aren’t ready for use yet.

    That way, programmers developing features that are more complex and take a longer time to complete aren’t prevented from integrating their work often and benefiting from it.

    Enabling A/B Testing

    The adoption of feature flags enables the use of several valuable practices in the software development process, one of which is A/B testing.

    A/B testing is a user experience research technique that consists of comparing two versions of a website or application to decide which one to keep. It entails randomly splitting users into two groups, A and B, and then delivering a different version of the application to each group. One group might receive the current production version, which we call the “control,” whereas the second group would receive the candidate for the new version, called the “treatment.”

    The testers then monitor the behavior of both groups and determine which of the versions achieved better results.

    Feature flags are a practical way to enable A/B testing because they allow you to quickly and conveniently change between the control and treatment versions of your application.

    FeatureFlags KillSwitch 2

    Enabling Canary Releases

    If you deliver the new version of your app to your entire userbase at once, 100 percent of your users will be impacted if the release is bad in some way. What if you could gradually roll out the new version instead? You’d first deploy to a small subset of users, monitoring that group to detect issues. If something went wrong, you could roll it back. If everything looked fine, you could then gradually release the version for larger groups.

    That’s a canary release in a nutshell. It’s another powerful technique that feature flags might help with.

    Customizing Features According to Users’ Preferences

    It’s not uncommon to have to customize your application according to the needs of specific users, and there are several ways in which software teams can accomplish that—some more efficient, and others less so (companies that create separate branches or entire repositories for each client come to mind).

    This is another area where feature flags could help, allowing teams to dynamically switch between different versions of the same functionality.

    Disable Code in Production 101

    How do you go about disabling code? That’s what we’re going to see now, in three increasingly sophisticated phases.

    First Stage: The Most Basic Approach

    We start with an approach that’s so primitive, it maybe shouldn’t be considered a feature flag at all. Consider the pseudocode below:

    calculateAdditionalWorkHours(Employee employee, Date start, Date end) {

    // return calculateAdditionalWorkHoursSameOldWay(employee, start, end);

    return calculateAdditionalWorkHoursImproved(employee, start, end);

    }

    In the code above, we’re just commenting out the old version of some method and replacing it with a new version. When we want the older version to be used, we just do the opposite. (Well, I said it was primitive.) This approach lacks one of the most fundamental properties of a feature flag—the ability to change how the application behaves without changing its code.

    However, it plants the seed for more sophisticated approaches.

    Second Stage: Taking the Decision Out of the Code

    The previous approach didn’t allow developers to select the desired version of the feature without changing the code. Fortunately, that’s not so hard to do. First, we introduce a logical variable to determine which version we’re going to use:

    calculateAdditionalWorkHours(Employee employee, Date start, Date end) {

     

        var result = useNewCalculation

    ? calculateAdditionalWorkHoursImproved(employee, start, end)

    : calculateAdditionalWorkHoursSameOldWay(employee, start, end);

     

        return result;

    }

    Then, we use some mechanism to be able to assign the value to the variable from an external source. We could use a configuration file:

    var useNewCalculation = config[newCalculation];

    Passing arguments to the application might be another option. What matters is that we now have the ability to modify how the app behaves from the outside, which is a great step toward “true” feature flagging.

    Keep in mind that the code examples you see are all pseudocode. Using your favorite programming language, there’s nothing stopping you from starting with this approach and taking it up a notch. You could, for instance, use classes to represent the features and design patterns (e.g., factories) to avoid if statements.

    FeatureFlags KillSwitch

    Stage 3: Full-Fledged Feature Flag Management

    The previous approach might be enough when your application has only a small number of flags. But as that number grows, things start to become messy.

    First, you have the issue of technical debt. Manually implemented feature flags can create terribly confusing conditional flows in your codebase. That only grows worse with new flags being introduced each day. Additionally, they might make the code harder to understand and navigate, especially for more junior developers, which is an invitation for bugs.

    Another problem is that as the number of flags grows, it becomes more and more common to forget to delete old, obsolete ones.

    The main problem of a homegrown approach is that it doesn’t give you an easy way to see and manage all of your flags at once. That’s why our third and final stage is a single piece of advice: Instead of rolling out your own feature flags approach, adopt a third-party feature flag management system.

    Feature Flags Kill Switch 3

    Feature Flags Are a CI/CD Enabler

    We’ve covered the mechanisms developers can use to disable portions of their codebase in production without having to touch the code. This capability is powerful and enables techniques such as A/B testing and canary releases, which are all hallmarks of a modern, agile-based software development process.

    The names for the techniques might vary—feature flags, feature toggles, feature flipper, and so on. The way in which the techniques are implemented can also vary—from a humble if statement to sophisticated cloud-based solutions.

    But no matter what you call them, you can’t overstate the benefit these mechanisms offer. They’re an enabler of Continuous Integration, which is essential for any modern software organization that wants to stay afloat.

    Carlos Schults is a .NET software developer with experience in both desktop and web development, and he’s now trying his hand at mobile. He has a passion for writing clean and concise code, and he’s interested in practices that help you improve app health, such as code review, automated testing, and continuous build.

     

     

  • All CloudBees (Approved and Proprietary) Tier 1 Plugins Support Configuration as Code

    All CloudBees (Approved and Proprietary) Tier 1 Plugins Support Configuration as Code

    Plugin Configuration

    So how do plugins come into this picture? As you may know Jenkins and CloudBees CI are largely the sum of the plugins that have been installed. A lot of these plugins come with their own configuration, which is used to customize their behavior or define what they integrate with.

    Below is an example of a YAML configuration for the Kube Agent Management Plugin. This is a plugin which is used for configuring the Kubernetes Pod template for worker agents.

    CloudBees has been working hard at delivering Configuration as Code (CasC) for CloudBees CI. A significant milestone has been reached this week with full support for all Tier 1 plugins for Configuration as Code. This key milestone coincides with Configuration as Code becoming generally available (GA) for CloudBees CI at the end of May. But before we talk about this milestone let’s first talk about what configuration as code is in general.

    Configuration as Code Introduction

    A key concept in cloud native DevOps is Everything as Code.

    In the Everything as Code world that we live in now, you can use code-management tools to deal with complex things like configuring and customizing your applications and infrastructure. This allows you to make use of tools like version control, code comparison and replication for things that you would traditionally have to configure using a point-and-click user interface.

    CloudBees CI and Jenkins are no exception to the Everything as Code model. As anyone who has set up a new Jenkins instance knows, this can be a detailed, time-consuming process, especially when you’re using the Manage Jenkins UI to do everything.

    Configuration as code considerably simplifies the configuration of CloudBees CI. With configuration as code, you can turn complex configurations into easily-replicated, human-readable code files (YAML). You can manage those configuration files with source control tools like GitHub.

    Tier 1 Plugin Support

    Tier 1 plugins consist of both Verified & Proprietary plugins – 124 plugins to be exact. Enabling Configuration as Code support for all of them was a large undertaking but a necessary one as it made the management and governance of all them dramatically simpler. We also added test cases to make sure that future changes to the plugins don’t unexpectedly break configuration as code functionality.

    Documentation for CloudBees CI Configuration as Code

    Full documentation can be found here:

    Link to Documentation for CloudBees CI Configuration as Code (Modern Platforms)

    Link to Documentation CloudBees CI Configuration as Code (Traditional Platforms)

    Documentation for Tier 1 Plugins Supporting Configuration as Code (Modern Platforms)

    Documentation for Tier 1 Plugins Supporting Configuration as Code (Traditional Platforms)

    Future Tier 2 Plugin Support

    Currently, CloudBees does not support configuration as code for Tier 2 plugins. These are also referred to as Compatible Plugins. Out of the 112 Tier 2 plugins we have work planned to add support for Configuration as Code for 38 of these plugins. The remainder either do not require any configuration or already support configuration as code. The work to enable support for the Tier 2 plugins is planned for release in the fall of 2020. Tier 2 plugin enablement will be released piecemeal, so certain Tier 2 plugins will be released much earlier.

    Community Credit

    CloudBees CI Configuration as Code is built on top of open source Jenkins Configuration as Code. We would like to recognize all of the work which has been done in the open source community on this feature.

    Any feedback or questions regarding CloudBees Configuration as Code in general or support of Tier 1 plugins is always welcome.