Galaxy Talks: Launching Darkly at Large Organizations

Welcome to our ongoing series spotlighting different talks from our interactive user conference, Galaxy, which was held in April. 

At large organizations, a successful software purchase isn't as simple as a credit card swipe.

From technical and security vetting to rollout and adoption, there are a lot of logistical elements to consider. You'll likely have many different stakeholders that will need to realize the software's value both ahead of the actual purchase and, perhaps more importantly, in the months afterwards.

All of this can feel initially daunting to a new buyer, but if you're assured of the value the software will bring to your team, there are lots of resources available that can guide you.

In that spirit, Aaron Kaka, solution architect for Pearson—the world’s leading learning company—walks us through the decision-making process that led to selecting LaunchDarkly, as well as some key points of consideration during the implementation phase.

Transcript:

Hi, everyone. My name is Aaron Kaka, and I'm a solution architect for Pearson, the world's leading digital learning company. This is my first presentation at a conference, and little did I know, it would finally occur during a time of pandemic. But I'd like to think that makes this topic that much more relevant given that we all are finding ways to be more flexible in this new normal. My goal is to share a story, albeit presented using an abstraction of how Pearson, as a large organization, came to successfully onboard LaunchDarkly.

If this helps you with a similar challenge, then industries across the software spectrum benefit from this expedited path to innovation and agility. 

How do you bring technical agility to large organizations? Many have found there to be common challenges in the situation. Let's take a look at a case study. 

Pearson is a London-based company that has grown from its inception as a construction business in the 1840s, but switched to publishing in the 1920s. It is the largest education company and was once the largest book publisher in the world.

And now, it has transformed itself into a- a digital consumer platform. Part of its growth and organizational structure has evolved organically due to corporate acquisitions over the years. This can lead to different lines of business, heterogeneous text stacks, organizational silos, complexity in budget allocation, and even cultural differences across the geos of the company. Moreover, it can take quite a bit of communication to determine all of the stakeholders for your cog in this machinery.

I'd like to discuss an approach that worked at Pearson in case it can help light the way at your organization. My caveat is that every org is different, so please understand your mileage may vary, but perhaps you can take an analogous approach that works for you. Please note that I'm not using actual Pearson people in the following slides. As for obvious reasons, I didn't want to reveal anything personally identifiable at my company. It isn't the names that matter, but rather the overall strategy.

On Project X, the product manager, Micky, comes to his engineering team and says that we need more agility to meet new and expanding markets. 

He wants to A: allow our dev teams to deploy code with less impact from dependent teams, so we don't have to continue juggling bottlenecks in our deployment schedules. B: allow product to turn features on and off without requiring developer involvement or deployment. In this way, we could turn features on when the market is ready or turn it off if we are seeing a lot of customer complaints immediately. And C: allow A/B testing for specific customers or a percentage of customers to see a specific feature.

After a discussion within engineering, there is consensus that Jackson, our friendly solution architect, should look into what options are available from external vendors. This is because he knows one: no one individual or group internal to Pearson has lit this challenge yet. And two: this solution will be demanded by more than just Project X. And three: from experience, he knows that Pearson should focus on its core business rather than rolling our own solution every time an enabling capability is needed. And- and there would be a surprising amount of engineering resources to consider when building your own enterprise feature management service.

Jackson discovers there's a name for the type of A/B testing product wants: ring deployment. This diagram shows you can start with specifying an internal set of users to receive the new feature. This can move externally to a group of end users who have agreed to try out the new feature. More broadly, you can then perform a random rollout to a percentage of users, while the others continue seeing the existing implementation. Finally, you do a general release of the new feature after it has tested well and met your QE standards.

So Jackson does the research to find out what's out there. He quickly sees that there are two classes of capabilities: those with feature flag management and those with some form of experimentation but lacking feature flag management. The latter, uh, is ruled out. Of the former, Jackson evaluates the services based on a set of criteria that would most benefit his organization. This could be a combination of technical and organizational attributes. Um, Jackson even selects three of the vendors' SDKs on which to perform a quick proof of concept.

I'm talking about carving out a half day for each, just to ensure it works as advertised, or to get a feel for how it would work in a specific text stack. All of this is documented in a table or a spreadsheet for future reference. From the POCs, Jackson selects the best option. In this case, it happens to be LaunchDarkly, and now he plans a proof of value implemented in a separate code branch. This is where he determines, with product and engineering’s input, a low stakes feature that can be implemented with LaunchDarkly to prove its worth based on product's stated needs.

The POV is documented in Confluence, planned using Jira, and assigned a dev resource, Shana, for implementation with Jackson's guidance. Once Jackson and Shana are satisfied they met the objectives of the POV, they do a live demo to the stakeholders. This includes not only the product QE and engineering managers from Project X, but leadership from partner teams, enabling services, and director level management. This is critical for getting buy-in from, uh, from your stakeholders because, uh, I mean, you're- you're going to have to show them a fairly comprehensive demo with some wow factor.

Perhaps things like, uh, you can update the flag external to your app and in less than 200 milliseconds, the update occurs in your app without a page refresh. Or the ease of, uh, building dynamic business rules for a variation based on the core start date. And showing the ease of setting up a percentage rollout. If done right, now your stakeholders are truly going to be the ones to make this all a reality. I also found it of great value to record a demo and store it on a company site that is accessible to all. This saves, uh, a great amount of time by not having to set up a live demo every time someone else in the organization wants to get a sense of what all that Project X fuss is about.

And keep it pivvy, because your colleagues are busy people and so are you. When asked, you can simply say, "Here's a link to a nine-minute demo. Please let me know if you have any questions." 

Now, with the groundswell of support from your stakeholders, Micky and Jackson are empowered to talk to someone like David, the director of- of DevOps, who will arrange for an enterprise architecture and security review of the vendor, and begin to process a procurement. The negotiations can begin, and architecture review board convened, and a contract eventually signed. Now realistically, this process may take many weeks in your organization.

But at its successful conclusion, Project X is set to deploy this new capability in production and with a- a feature already behind a LaunchDarkly feature flag. 

For your Project X, establish best practices that can be set for the teams that follow your lead. Track your flag creation and eventual deletion in your tool of choice. In our case, it is Jira. Uh, set up custom roles for each project so that dev and QE are scoped to their own project and don't inadvertently change others. Set up a naming standard that will help keep track of flags, especially when you end up with 30 or 100. We found it helpful to include the Jira number.

Tag the flags as well to make them, uh, to make filtering them by functional area easier in the LaunchDarkly interface. Set up integration with code references in the build pipeline so that the interface can show you exactly and what file, and even what line number of code you have a reference to each flag. Last but not least, protect your keys, especially in front end integrations by implementing secure mode. Document all this somewhere as a handy company guide.

So word spreads. Um, and this is word of success especially when you have sentiments as expressed by Kim, a senior management of development with whom I work closely at Pearson, when she said this took our agility to the next level. Another way to say this might be that success spreads like a virus. Product managers for, uh, other projects will beat down your door to find out how they can do what you're doing on Project X. I must say crucial to this was the support we received from LaunchDarkly themselves. They assigned us a customer success manager and I have to give a shout out to LaunchDarkly's Vernon Gomes.

He even facilitated technical discussions and the passing around of JSUN definitions for Pearson's custom roles to get us exactly what we needed. Good times, so thanks for that, Vernon. 

And they are only too happy to provide live training to Pearson staff with live Q&A upon request. They even record the sessions and provide the- the links to pass around. It truly feels like a partnership for mutual success. There's always more peaks to scale. In the near future, we hope to work towards single sign-on, which will enable things like administrators to onboard and new employees from our identity provider without having to also create accounts for them separately in LaunchDarkly.

There are a couple of add-on features we are considering. We'd like to be able to export the LaunchDarkly data to our data lake to enable user analytics and- and ad-hoc queries. Additionally, there is experimentation where we can set up metrics for our feature flags and see a realtime dashboard. Until this is in place, we think we found a way to do a simplified version of this. 

Thank you for your interest and attention and- and remember that innovation can happen anywhere.

From LaunchDarkly tips and tricks to supercharging your release pipeline, check out the rest of the talks from Galaxy.