Microservices Architecture: Developing a Business Case and Key Considerations for a Progressive Approach

In our previous post we broadly discussed the mindset of composable business. While “composable” can be a long term company-wide strategy for the future, companies shouldn’t overlook smaller-scale opportunities that exist at every level to introduce more flexibility, longevity, and reduce costs of technology investments.

For maximum ROI, think big, then start small

Many organizations are daunted by the concept of shifting a legacy application or monolith to a microservices architecture. This is exacerbated when an application is nearing end of life.

Don’t discount the fact that a move to a microservices architecture can be done progressively over time, unlike the replatform of a monolith which is a huge investment in both time and money that may not be realized for years until the new application is ready to deploy.

A progressive approach allows organizations to:

  • Move faster and allow for adjustments as needed
  • Begin realizing returns on investments faster
  • Reduce risk by making smaller investments and deployments
  • Ease budgeting process by funding an overhaul in stages
  • Improve quality by minimizing the scope of tests
  • Save money on initial investment and maintenance where services are centralized
  • Benefit from longevity of a component-based system

Prioritizing the approach by aligning technical architecture with business objectives

As with any application development initiative, aligning business objectives with technology decisions is essential. Unlike replatforming a monolith, however, prioritizing and planning the order of development and deployments is crucial to the success of the initiative.

Start with clearly defining your application with a requirements and feature matrix. Then evaluate each using three lenses to see priorities begin to emerge:

  1. With a current state lens, evaluate each item. Is it broken? Is it costly to maintain? Is it leveraged by multiple business units or external applications?
  2. Then with a future state lens, evaluate each item. Could it be significantly improved? Could it be leveraged by other business units? Could it be leveraged outside the organization (partners, etc…)? Could it be leveraged in other applications, devices, or locations?
  3. Lastly, evaluate the emerging priority items with a cost and effort lense. What is the level of effort to develop the feature as a service? What is the likely duration of the effort?

Key considerations when planning a progressive approach

Planning is critical to any successful application development initiative, and architecting a microservices based architecture is no different. Be sure to consider the following key items as part of your planning exercises:

  1. Remember that rearchitecting a monolith feature as a service can open the door to new opportunities and new ways of thinking. It is helpful to ask “If this feature was a stand alone service, we could __
  2. Be careful of designing services that are too big in scope. Work diligently to break down the application into the smallest possible parts, even if it is later determined that some should be grouped together
  3. Keep security front of mind. Where a monolith may have allowed for a straightforward security management policy with everything under one roof, a services architecture provides the opportunity for a more customized security policy, and the need to define how separate services are allowed to communicate with each other and the outside world

In summary

A microservices architecture is an approach that can help organizations move faster, be more flexible and agile, and reduce costs on development and maintenance of software applications. By taking a progressive approach when architecting a monolith application, businesses can move quickly, reduce risk, improve quality, and reduce costs.

If you’re interested in introducing composability to your organization, we’d love to help! Contact us today to talk about your options.

Related tags: APIs Composable Business Design Systems Microservices Technical Architecture

ARTICLE AUTHOR

More about this author

Chris Murray

Founder & CEO

Hey, I’m Chris. I started Oomph what feels like many moons ago, back in 2007. It’s been quite a journey and I have been lucky enough to assemble an amazing team that keeps me energized and ready to tackle each new day.

My main focus as CEO is making sure Oomph is a great place to work, setting the vision and goals for the future of the company, and supporting the team to get us there. I also love getting to know and strategizing with our clients and seeing the positive impact technology can have on their business.

Before founding Oomph, I ran the Boston office for an early web development agency where I led a team that guided digital strategies for clients like Polaroid, Reebok and Stonyfield Farm. We also brought a content management system to market with both open source and SaaS offerings.

I am an active member of the Entrepreneur's Organization and live in Dartmouth, Massachusetts with my wife and three daughters.