Why I Gave My Engineering Team a Chance for a Do-Over - InformationWeek
IoT
IoT
DevOps
Commentary
8/22/2017
07:30 AM
Brent Cromley Jr., SVP of Engineering, Zuora
Brent Cromley Jr., SVP of Engineering, Zuora
Commentary
50%
50%

Why I Gave My Engineering Team a Chance for a Do-Over

Transforming to a microservices architecture requires coordination across all disciplines. It won't be easy, but it promises plenty of benefits.

“Don’t reinvent the wheel,” the idiom cautions us. It’s a phrase that seems wise on the surface, a reminder to not spend time creating something that already exists. Too often, however, the idiom has been deployed as an admonition, a warning to not upset the way things are, even when those things are outmoded or just plain wrong.

Creative engineering minds, thankfully, generally ignore that kind of advice or we would all still try to get around on wooden rims and spokes. Wheels -- and many other things -- do frequently need to be reinvented to take advantage of advances in technology and changes in customer needs.

Technology companies are at such a moment of inflection now. Even as they have invested in monolithic applications, they have had to shoulder the limitations imposed by the size of their code and their inability to handle independent scaling. Many now understand that they will need to transition from a monolithic application to a microservices architecture in order to better position themselves for future growth and product development. A microservices architecture offers greater global accessibility and enhanced functionality for customers. It makes it possible to iterate new features and improvements as they naturally occur and creates a flexible platform for the integration of future products and features.

Shifting from a monolithic application to a microservices architecture also enables engineering teams to innovate at the pace inherent to that team and to scale up based on the needs of the specific microservices they are developing. The shift allows the team’s technical vitality and innate innovation to flourish as they experiment to find the best way to deliver new functionality. It frees an organization’s best minds to try, and occasionally fail, without compromising a product as a whole.

Nevertheless, as they reinvent their respective wheels, leaders of engineering organizations should know that there are five challenges they will face as they transition:

1. Embrace cross-functional complexity. If your organization has not already taken down the walls between engineering, product, tech-ops and QA, the first steps towards your new direction must begin there. The goal is to build cross-functional teams focused on overall product features and delivery, not merely looking to add next-gen bells and whistles to an existing product.

All of us in this field know Conway’s Law, but we don’t often set up the foundation for change in a way that will avert a collision with it. There is no easy path to a microservices architecture from a monolithic environment. Leaders must resist the impulse to simply build a new monolith and migrate over to it when it seems done; they must embrace the nuances and complexity and reinvent their product at its core based on the needs of the business and functionality, not just technological feasibility.

2. Let metrics drive. With a cross-functional team in place, the next step is to break up the existing system incrementally, taking it apart functional module by functional module and reinventing each one in turn, with the right metrics top of mind. We learned that replicating an existing functionality into the new services alone was not enough; each engineering leader had to define success metrics for every new service.

Leaders must define the cost metrics of the changes that they are envisioning and clearly communicate them to their engineering organization, and they must make sure that engineering has all the data it needs to make appropriate, data-driven decisions. There must be checks and balances such as frequent and recurring design reviews to keep the work aligned with company objectives.

3. Automate, automate, automate. Tech teams also need to be encouraged to move away from a narrow reliance on tickets to address features and feature bugs. Our own infrastructure engineering team learned to scale from solving individual problems to building tools that enabled different microservice teams to solve problems. Process and handoffs have to be supplanted by tools, with an emphasis on automated tools. In a simple environment, one can have a single team member look at a graph. If latency breaks a threshold, a troubleshooter can be called in. With a complex environment, all of this must be automated.

4. Make mistakes and learn. We’ve learned a lot from the past two years, and have made it a goal to share learnings in engineering all-hands meetings every month. To successfully implement a transition to a microservices architecture, teams must have frequent working sessions around the APIs they are creating, as well as around the functional changes that will be needed in each of the envisioned microservices.

As they work, they must be given time not only to put forward new ideas, but to make mistakes and to learn from them. To circle back to the wheel analogy, remember that the original models didn’t have rims or tires. Both were innovations brought about through learning about how people were using the wheels, and feedback regarding what more they desired them to do.

5. Grow into the new approach. Leaders must also acknowledge that the existing company and its monolithic application must continue to thrive during the transformation process. That will mean starting the microservices transition with a small team and then growing incrementally as each success is achieved. Zuora began its transition with a team of only two, and has made progressive investments to expand the team to its present size of over 30. Leaders must also take care to avoid labeling their engineers as two separate teams (e.g. the “old” monolithic application team and the “new” microservices team).

All team members are needed to maintain the company’s growth and development, and there should be opportunities for all engineers to participate and move forward with the new direction. Zuora's practice is that a single team will own the same functions in the monolith and in new microservices. This team will be responsible for reinventing the functions in the monolith into new microservices, migrating existing customers to the new microservices, and sun-setting the functions in the monolith. This is how everybody participates in and contributes to the reinvent initiative.

Transforming to a microservices architecture requires a transformation across all disciplines: engineering, QA, program management, operations and product management, as well as customer support. It will not be easy work, but a shift to a microservices architecture will provide ancillary benefits well beyond primary goals because it brings consumer-level scale and architecture into the enterprise and makes it easier to take advantage of changes in the computing and technology landscape. It also allows each microservices product team to act as a mini-startup company within the organization that owns its own destiny, innovates at the speed of its brightest minds and maps its own journey--which it will travel on an ever-adaptable set of wheels.

Brent Cromley
Brent Cromley

Brent Cromley, Jr. is the senior vice president of engineering at Zuora, Inc., a SaaS company that is an evangelist of the Subscription Economy. A graduate of Dartmouth College, Cromley joined Zuora in 2016 from Zappos, having grown its tech team from 15 engineers to more than 250 worldwide.

The InformationWeek community brings together IT practitioners and industry experts with IT advice, education, and opinions. We strive to highlight technology executives and subject matter experts and use their knowledge and experiences to help our audience of IT ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
2017 State of IT Report
2017 State of IT Report
In today's technology-driven world, "innovation" has become a basic expectation. IT leaders are tasked with making technical magic, improving customer experience, and boosting the bottom line -- yet often without any increase to the IT budget. How are organizations striking the balance between new initiatives and cost control? Download our report to learn about the biggest challenges and how savvy IT executives are overcoming them.
Register for InformationWeek Newsletters
White Papers
Current Issue
Top IT Trends for 2018
As we enter a new year of technology planning, find out about the hot technologies organizations are using to advance their businesses and where the experts say IT is heading.
Video
Slideshows
Twitter Feed
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.
Flash Poll