Reaping the Fruits of Service Integration

I work for Intuit, a well-established company that keeps reinventing itself to thrive in the ever-changing modern economy. Micro services hold the key for the company’s vision.

I have covered the inevitable process of converting our monolith code into services in a previous post. Now we are getting to the fun part: the actual benefits Intuit gains from having the new services.

Integrations, Integrations, Integrations

In the end, it all boils down to Integrations: our acquired startup (and monolith) was good at doing some specific work, but buying the startup wasn’t about keeping the existing business model and letting it run under a new management, it was about leveraging the core functionalities and building new and exciting capabilities.

Integrations are exactly that: combining different existing pieces or products to create something new.

Success is measured by the amount of different and non-trivial integrations and by how hard and how long did it take to make them. A service is measured by the amount of traffic and integrations you have.

In our case, the first (and minor) integration we did had set the stage for the second (and strategic) successful integration. The traffic to our service has increased around 100 times. We are now on the verge of integrating with more teams and projects and the future seems brighter than ever.

Minimize Dependencies to Maximize Speed

Monoliths are all about dependencies. We can’t have that if we want to allow our teams to move as fast as they can.

I am not saying that services or the service architecture does not have dependencies, but rather suggesting that the amount of coupling is significantly less than the alternative.

Once you break down the product into services and have correlating teams, the speed of many teams is increased, as they are being unblocked and empowered to do the needed changes in their own domain to face the new requirements.

Ownership and Mastery

Ownership (autonomy) and Mastery are key for any expert in any field. Services are perfect to achieve that.

A service is owned by a single team. This team is responsible for the health and future of the service. This creates a sense of ownership in the team. In addition, since there are fewer dependencies, the team has the autonomy to make the call as to how to get things done.

This autonomy breeds mastery. If you own a service, you start caring about it and look for ways to make it better; this process makes you a better engineer.

Operational Scale

No, I’m not talking about user traffic load of anything in that area (although services can help in that area as well).

What I am actually referring is the operational overhead: what would it take to run your team if you get ten times more work than you are getting now?

Think about those few samples of operational work increase: how would your team be able to cope with 500 weekly customer care issues instead of your existing 50? How would you be able to deploy, maintain and monitor ten times more servers than you have now? How would your service and your team cope with ten simultaneous integration requests by other teams?

To make things harder, all of that has to be done with the same staff you have now.

It turns out that service architecture can help you to achieve just that: Minimizing dependencies allows the team to move much faster and achieve much more in the same time period, while creating an environment which supports Ownership and Mastery increases engagements and eliminates turf disputes.

Surprise and Innovation

If you set the stage correctly, you will find that individuals have the capacity to surprise you. They have the ability to innovate and to come up with ideas and implementations you didn’t think were possible.

Service architecture is just right for innovation: it empowers utilization of generic capabilities, without the worry of breaking something.

Services achieve that by generic interfaces and decoupling. It’s that simple if you follow these principals.

Conclusion

The list above contains some of the key benefits of moving to a service architecture. Many of them may seem difficult to achieve. In fact, they are a byproduct of the services architecture: the more you invest in creating micro services, the more your team adapts and later leverages the service platform that was created.

With the move to the services architecture, Intuit expect teams to move faster, to operate more effectively and to create new and innovative products.