AMA Software Development — A Retrospective
Author: Collin Moody, Chief Transformation Officer
Over my career with AMA, I’ve heard the same thing time and time again from new employees: “I had no idea how much AMA does!”. It’s not until you’ve spent a few weeks at AMA that you understand the breadth and complexity of our businesses. Insurance, Banking, Travel, Rewards, etc. — we are in some of the most fiercely competitive industries and have faced significant challenges over the years.
As a small regional company, we are a bit of a David vs Goliath story in many ways. We’ve had to learn quickly and think differently about how we respond to these enormous competitive threats while focusing on delivering member value.
Cue technology.
What was once our Achilles heel is now rapidly becoming our key enabler, but it has taken sustained and focused effort to identify a path forward. If we’re being honest, we were in a bad state a few years back. Most of our technology was built upon antiquated monoliths, incapable of taking us where we needed to go. We knew we had to do better and be competitive, and we couldn’t just be as good as everyone else: we had to be better and harness speed and agility as our key differentiators.
Our plan of attack was as follows:
- Unapologetically copy the best
- Focus on team topology
- Be intentional about architecture
- Be smart about what you build
Here’s what we did:
Unapologetically Copy the Best
Love or hate them, we knew early on that Amazon exhibited unparalleled speed and agility, and as a result had some amazing lessons for us. We dove deep into their inner workings trying to understand how they were structured and what we could do at AMA to lever some of that.
Taking a trip to Amazon headquarters a few years back was a bit of a “kid in a candy store” experience. There we learned about what makes agility: 2 pizza teams, the importance of integration architecture, and the criticality of creating an environment which empowers team members to make decisions around technology. Architecture-wise, we also learned about the importance of building a foundation on microservices. Unlike traditional monolithic systems, microservices allowed for nearly infinite and rapid expansion of new services and their underlying support structure.
I’m sure AMA is no Amazon, but we recognized two critical must-do’s — we had to stop dabbling and move all in on microservices and build a commensurate team topology to support it.
Focus on Team Topology
I can’t talk about our journey without pointing to one book that influenced much of our decision-making: Team Topologies: Organizing Business and Technology Teams for Fast Flow (Mathew Skelton, 2019). This book, in real terms, reinforced the importance of investing in an organizational structure streamlined to deliver with pace. It also made a case for a very strong correlation between team dynamics, empowerment, and organizational success.
In support of our transformation, we embraced team topology as an asset and began to align teams with our delivery streams and microservices architecture. We haven’t yet perfected our team topology, but we are ever experimenting and improving as we learn more about how our organization finds pace.
Being Intentional about Architecture
Unchecked, our ungoverned architecture was fast becoming a liability to our organizational potential. As we tackled the problem of misaligned architecture, we had to resist the temptation to build a strict, top-down enterprise architecture office, which we knew would completely stifle our growth and progress.
So, how did we find the right balance? For us, the answer came through a bit of introspection (around our previous architecture failures). With the help of the Scaled Agile Framework (SAFe), we built a common understanding and approach toward architecture. Fundamental to our advancement was the epiphany that both Intentional Architecture and Enabling Architecture are vital to an enterprise framework (this could be a whole topic for another blog post).
Under the watchful leadership of our Director of Enterprise Architecture, we crafted a program that created the rails for our teams to ride: the heart of the program is not enforcement, but rather enablement. By creating shared ownership, embedding architects on all software development teams, and encouraging those architecture working groups to embrace new technology stacks, we have developed a collective responsibility around our common architecture.
Now architecture is not an abstract concept nor a program to be feared, but rather is an enabler that powers our progress.
Be Smart About What You Build
When you build out a powerful discipline around software development like we have at AMA, it is easy to believe that everything and anything needs to be developed from scratch (the old “everything is a nail when you have a hammer” adage). But it’s clear that there are enabling platforms designed to do niche jobs well and, if integrated with intent, can form the basis of service delivery.
For example, as we approached replacing our legacy membership system, it was clear that the unique intellectual property we should develop was around how we enable our business partners to create flexible membership constructs to respond to new and emerging member expectations. What we didn’t need was to rebuild our payment platform — surely, this was something that others had perfected. As it turned out, we were right. So we opted to integrate a best-in-class payment and subscriptions platform with our internally built microservices to create a flexible membership management and payment platform. We know that the payment platform will continue to evolve with new and emerging customer expectations, while we will continue to invest in developing unique solutions that address member value.
Being smart about being intentional in what you build is as important as building a strong software development discipline.
In Malcolm Gladwell’s book David and Goliath (Gladwell, 2013), he speaks to why underdogs win in situations where the odds are stacked against them. Through his research, he found that learning through hardship and competition creates an advantage and that leveraging unique skills is the key to beating competitors on one’s own terms.
At AMA, we don’t focus on our competitors as much as we focus on our member experiences. As we’ve expanded our technology department to match the demands of our members, we’ve done so by building upon a strong foundation designed to scale. With a focus on microservices, an aligned topology, and an intentional approach to architecture, we can now scale and adapt to changing member demands.
We now have over 80 software developers across our organization who are more empowered and engaged than ever, and we can see how the decisions we have made over the past few years have created a foundation for growth. I’m also aware that this is a journey, and we will make mistakes along the way as we continue to learn, evolve, and improve. As you can probably tell, I am extremely proud of what we’ve built and beyond excited about our potential as we capitalize on our underdog status and use our agility to create unparalleled products and services for our members!
My apologies to Goliath.
