Benefits of microservices from a business perspective

Nowadays, engineers are pushing business hard in the direction of microservice architectures – and for sure they are in many cases right to do so.

Leaving the big ball of mud applications and moving away from those legacy monolithic architectures, is from a technical perspective, often very beneficial. One argument might be “it is a good and proven way to restructure the inherent complexity our applications need to deal with”.

But that is only one part of the equation, let us also check the variables relevant for new business opportunities. So what are the benefits of microservices from a business perspective on top of better maintenance or scaled performance? There are at least three benefits we should explore: faster time to market, facilitating future business models and enabling technology revolution.

On the time-to-market waiting line

Publishing new functionalities on a frequent and regular basis is key for business. A short cycle time is a proven recipe for business success.

Knowing this, many also experience the blame game: “We are waiting for somebody else to accomplish a task first before we can proceed”. This song has surely sung, if you are are working together with others or are downstream of another delivery and you cannot release independently. In many cases you are stuck in a deployment model related to a monolithic architecture or inefficiently scaled process.

If you face that land of confusion, it is definitely a good thing to descale your product into several smaller services using functional decomposition. This will create more autonomous delivery teams providing valuable functionality on their own, and an independent pace for each service with the benefit of faster cycle times.

On the other hand – a bit counterintuitive – it might help to upscale your product development again. Once you have created clear boundaries with smaller teams you can add new people to your development team. By descaling your product into more decoupled parts you can increase the amount of independently working people within the boundaries of your microservices architecture.

Enabling future business models

Separation of concerns is a technical term every business should take advantage of because you can create business out of it.

Let’s consider a big product. Usually some parts of it – some concerns – are relevant to new customer segments. But these parts are stuck in the product as a whole by design coupled as joined value. Customers cannot consume it separately nor can you offer the services independently.

With functional decomposition of your concerns you are able to publish smaller value propositions in the market. You can enter markets which do not need your full solution but would benefit from some parts of it. Decomposing functionality and providing them als microservice unleashes value on another level: the parts can be as valuable as the sum, or even more as you introduce new value streams like subscription instead of one-time payment.

So the question remains: “Should you address those opportunities or do you rather want to hide your value in a big bundle?”

One more thing: Microservices come with APIs and the more APIs (interfaces) you have, the more you can publish to the world outside of your organisation. From now on you can decide to keep your functionality as an advantage, publish it as an API with revenue per usage or white-label it to sell or host the solution.

Stuck in legacy systems

Or another way of putting it: one technology to rule them all was usually a bad approach.

Reaping the benefits of new technology is key for successful digital products. But with big applications full of feature bundles you are usually trapped in an “old version of outdated technology problem”. The bigger the application, the more features, the bigger the problems.

So, if you cannot change the system fully and want to benefit from new technology, what can you do?

You already know it: Divide and conquer using microservices would be one good way to go. By incorporating this, you can subsequently extract functionality into new bundles and therefore introduce new approaches and ways of working with technology. With smaller more manageable chunks of technology under maintenance, you do have two key benefits: You can select the better technology and can more easily update or replace any given technology.

Using new technology will gain you access to more skilled people, extended version support, higher performance and flexibility in scaling, lower costs, extended functionality and higher adaptability of you product towards business needs and customer demands.

If you break down your application, keep together what belongs together. Key point is maintaining clean boundaries and a consistent domain model – both help you to keep the functional cohesion you need.

Microservices summary

Decomposing your big application into several parts using a microservice architecture can be a good and useful thing. Only following developers’ needs can distract you from the real benefits this approach provides. Therefore it might be more beneficial to do it for business reasons.

Microservices can be enablers for

• reducing the time-to-market, removing dependencies in scaled development, while delivering value more autonomously team by team
• new business models, providing you with the option to scale smaller parts of your application into independent business models
• new technology to use, giving you the chance to take advantage of up-to-date technology and people in the market – helping you to get away from legacy step by step

So, if your engineers push you to move towards a microservice architecture, you’ll be surprised to find value for your business and many opportunities will evolve.

Interested how your organization can benefit from microservices?

We are happy to talk to you about opportunities. Contact us at info@adorsys.com