At a recent division meeting, Jerry Sayre, Chief Software Engineer at Mutual of Omaha, donned a white lab coat and took to the stage. But rather than talking about technology, he spoke about the importance of experimentation and the use of the scientific method.
“We need to consider what is required for us to be able to quickly deliver new insurance products,” Sayre said. “How do we get there? Formulate hypotheses and test them. Experiment. Take that leap of faith. Considering our size and history, I realize it’s an unusual undertaking.”
The company’s newly formed Enterprise Business Platform Lab (EBPL) is departing from the established approach to insurance product development. Mutual of Omaha, a Fortune 500 insurance and financial services company founded in 1909, is creating its new disability insurance product “in the lab.”
The timing was perfect for this type of approach, according to Tim Darnall, Chief Technology Officer and Head of Enterprise Architecture. When internal business partners identified the need for a new disability insurance product, Darnall and Sayre determined cloud technologies, IT organization and company culture were all in a good place to start an experiment in … experimenting.
“We considered all of the technology options and asked, ‘How can we disrupt ourselves?’” said Darnall. “We believed Mutual of Omaha was at a place where a new approach aligned well with our culture and our commitment to innovating on behalf of our customers.”
Thanks to our sponsor
In other words, it was time for a clean-slate approach, unconstrained by past practice, yet leveraging what the company has learned over the last 110 years of being in business.
Acknowledging the newness of it all, Doug Schnoes, Business Systems Architect, compared the Enterprise Business Platform Lab to infancy in a business setting.
“EBPL is like a baby getting ready to roll over,” Schnoes said. “We’re evolving a target architecture, figuring out what that looks like, seizing the opportunity to build a platform – a modern, open API event-driven architecture that will make it possible for us to adapt to ever-evolving customer expectations.”
While the EBPL is still young, Schnoes said it’s maturing quickly.
“The EBP Agile Release Train kicked off quickly, after just one month of planning,” he noted. “Train formation happened in a week. We are still storming and norming, working with a new technology and a new operating model.”
The challenge for EBPL is to build the business platform with no shortcuts and on a solid foundation.
“We’re trying to ensure that the ‘urgent’ doesn’t trump the ‘important,’” Schnoes said.
Taking that into account, EBPL developers are following industry best practices for the development of open APIs and their work is rolling out to the enterprise. A project with some previous integration challenges ran a proof of concept using APIs developed in “the lab” and had success speeding up the implementation from months to weeks.
Both Amy Runyan, Agile Release Train Product Manager, and Glenn Miller, Agile Release Train Product Owner, believe the EBPL makes for a balanced partnership between IT and the product development teams.
Runyan sets business priorities for the train and defines product features.
“Working this way helps us maintain our focus on our customers,” Runyan said. “We need to invest in technology to be more efficient, reduce operating costs and provide levels of service that meet or exceed customer expectations.”
Miller works with the many business areas of the company that must provide data and other requirements for the product.
“We are starting from scratch,” Miller said. “It’s an adjustment to narrow down the 529 system requirements they identified to just the 75 or so that must be ready on day one. The concept of rolling out a minimum marketable product and improving it incrementally is new for all of us.”
At a recent planning session, Stephen Lynn, Principal Enterprise Architect, suggested to the EBPL Agile Release Train that what the company is creating is less like a puzzle, where each piece has one and only one purpose and position, and more like a model created with Legos. A small number of Legos (APIs) can be assembled to make an extremely large number of different models.
“No matter how good our decisions are today, they will likely evolve in the future,” Lynn said. “Our job is to figure out how we can be modular enough to adapt to that change.”
Despite the challenges that come with working in a new way, Lynn said everyone involved is excited and energized.
“The team is passionate about making a difference,” he said. “They have a strong will to succeed and know they are supported by a commitment from the top down.”
Eric Wade, Scrum Master for one of the feature teams said that building so many things from scratch simultaneously is very fulfilling.
“You’re on the ground floor, helping to establish the software foundations for the future of your company and making an impact,” Wade said. “Working on a great team and such an exciting project makes it fun to come into work every day.”
Runyan expressed enthusiasm about EBPL’s methods and progress.
“In my 40 years with the company I have never seen this approach of experimenting to find the best solution,” she said. “I’m excited about what’s happening now, but even more excited to see what happens next. I can’t wait to see how quickly we’ll be able to launch a new product solution without sacrificing quality.”
So what’s in store for the EBPL a year from now? Lynn predicts a more established model that can help the company introduce new solutions for customers much more quickly.
“We should be seeing the new capabilities spur innovation across our business,” he said. “The technology will support bringing a new product to market in weeks instead of years.”
With that in mind, the time and effort spent experimenting in the lab is worth every minute.
––
Annette Allen is a Sr. IT Consultant at Mutual of Omaha in Omaha, Nebraska.
