Q&A with Eli Lilly’s Software Engineering Lead: Focus on People, not Tech

👁 Image
Like many organizations, Eli Lilly started moving towards a DevOps approach as a way to focus less on managing infrastructure and tools and more one using technology to bring value to their own customers. According to Nick Liffen, software engineering team lead at Eli Lilly, the technical part of the move to a more cloud native approach is the easy part. Getting individuals and teams to not just use new technology, but also change how they work together and how they think about the relationship between different types of technologies has been, he said, the most challenging part of moving to cloud native — but also the most impactful.

We chatted with Liffen about why Eli Lilly started the cloud native journey, what the company has learned along the way and the specific compliance-related challenges pharmaceutical companies have to think about. His answers have been edited and condensed for clarity.

Can you tell me about Eli Lilly’s journey to cloud native?

Firstly, it’s still a journey. We started our cloud native journey many years ago now, and for us that started with moving our tools and services over to “as a Service.” It was about recognizing that we don’t need to host software management tools and continuous integration tools on-premises, and having GitHub, CloudBees and so on manage that for us. That’s where it started.

Then we started to move into cloud native application design more recently. That’s a more recent move for us, and we’re probably still quite immature in this area, though we’ve certainly made a lot of progress.

I think, when you think about a lot of large enterprises that were building things in monolithic, legacy ways and move to cloud native, for these enterprises technology normally isn’t the challenge. It’s about understanding what’s best and understanding what the best solutions are, and what a cloud native approach looks like. It’s quite important for the whole cloud native journey to focus on people and training because that is really the crux of success with cloud native.

What was the core motivation behind the move to cloud native? Were there push and pull factors?

As you think about modern use cases and modern agile business requirements and the need to do things at scale — those things just aren’t possible on an on-premises monolith. You can’t go scale to thousands of patients, in our case, or thousands of healthcare professionals, without literally staking servers in a data center.

Also, as we were hiring technical talent people would come in and say, hey, we should be doing things in this way. And we’d have to respond, oh, no we do things traditionally. That made it hard for us to hire the best people.

We really wanted to scale and make sure that when we deployed solutions we were able to meet end-user demand. We also just started to realize that we didn’t have to manage a lot of our tools ourselves. You really want your people focused on feeling empowered and enabled to meet business use cases, not sitting around upgrading tools.

Speaking of scale, have you had to scale up as a result of the coronavirus outbreak?

We haven’t had any end user demand that has forced us to scale up dramatically, but we’re lucky, because a lot of our applications are hosted on a platform as a service, so they could scale quite easily. We use Heroku Dynos to run and scale our containerized applications, so we could easily go from one Dyno to 10, 20 or 30.

We have had, for example, press releases that go out about specific Coronavirus testing locations that people can sign up for. That’s the kind of thing that would have made people nervous when they went to bed, but now we don’t even have to worry about it because it’s not our problem.

It seems like a small thing but being able to scale up at time of need can make a real difference. I don’t know if you can even put a real dollar value on that.

You clearly have to meet some compliance rules. How has that been a part of the cloud native journey for Eli Lilly?

As a pharmaceutical company, we clearly have a range of different requirements that we need to meet, including PHI, HIPAA and SOC. Over the last two or maybe even four to five years more and more cloud native technology companies are offering compliance out-of-the-box.

However, just because you have a Business Agreement for HIPAA compliance in place doesn’t mean that your data is 100% secure. It’s very much a two-way street. They have to do what they say they will do from their side, but there’s also onus on Lilly or any other company to ensure that our applications are built in the best way, and follow best practices, regarding compliance. I think that’s an area where some large enterprises are a bit naive, just because the third-party service says they’re HIPAA compliant doesn’t really mean that you don’t have to think about HIPAA. You absolutely do.

What can you do now that you couldn’t do before?

I think we’re able to spend much more time trying to meet business outcomes and actually deliver applications rather than building infrastructure and supporting that infrastructure. I haven’t had to become a subject matter expert in networking or in how operating systems work. I just trust that the third-party service that we’re using is handling that. Yes, you have to understand at a high level, but for the most part you can focus on your application.

Feature image via Pixabay.