Microservices Business Readiness

Originally authored by Dick Brown

Microservices is a hot topic in software development—when building new applications, we often hear the phrase: “…make sure it’s in a microservices architecture.” While microservices are a great choice in the right situation, it’s not the right choice for every situation. Whether building something to replace an application or breaking down an existing monolith, microservices can drive a ton of value, but the effort required to complete such a project is large, and the timeline is long. Trying to build a distributed architecture may not always yield as large a return as the effort required if you’re not prepared. Therefore, let your microservice be born out of necessity and not nicety. You can prepare your application, your teams, and your organization by looking at some of the key business considerations before diving into the technical end. Evaluating your microservices readiness will help you understand what it takes to be successful.

Microservices readiness questions

Microservices readiness: Knowing your business and applications

How established is the business model?

This has two parts. First, your company’s business model can’t be in a variable state; it must be in a stable place, so needs are not in flux. Stability should persist throughout the microservices engagement. Second, the business model needs to be mature: A startup is not the place for microservices. There’s no reason a net-new application or an application to meet the needs of a net-new business model can’t be built with the flexibility to spin off services as needed. However, wasting go-to-market time establishing business boundaries as you strive to achieve a microservice architecture is inefficient. If your application doesn’t qualify for microservices, you should still build a flexible, scalable, and lightweight architecture in “vertical slices.” This gives you the option to adopt a microservices architecture at a later date when it does qualify.

Do you have a nominated expert or set of experts?

Each component/feature in a legacy system requires an expert/owner. This is a difficult ask. As applications develop tenure, knowledge leaders exit, and not all information is documented or distributed to the team properly. It’s possible that you’re in a place where there are no longer any application experts. Key operational features or technologies have either worked without issue or been duct-taped together so badly that nobody can sort it. If that’s the case, you need to nominate new experts.

Make sure the recognized experts are involved with discovery and architecture design for the future state of the application. If you’ve partnered with consultants or an external development team, they’ll rely on the intimate knowledge these experts bring when they have questions. Identifying these owner(s) and keeping them engaged is critical. Also, the owner might not be someone who sits behind a desk—it might be the person working on the shop floor who knows their job better than anyone else. You’re ready to move forward only when there’s working knowledge of all the technology and features that the application currently uses. Without this, you’ll stumble from working too many steps ahead without the proper foundation.

What obstacles are you trying to overcome?

Know the limitations of the current technology and assign a measurement to the difficulty it causes, whether it’s enhancement requests you can’t address, development time, time to deploy, or other pain points. Begin by researching the concerns raised by developers. Understanding development pain and system complexity have just as much value as customer complaints. Removing internal blockers first will allow you to resolve bugs and release features faster, resulting in resolved customer issues. Also, understand that not all problems are solved with a silver bullet: Determine what are acceptable pain points (all applications have them), and what are hindrances that need to be overcome. This will serve you greatly throughout the project.

Where are you going to start?

Identify what feature or business boundary will qualify for the first microservice(s). This evaluation will help you build a rough order of operations. This feature doesn’t need to be an existing one. If there is a new feature that’s impossible in the existing tech stack (or very difficult), that may be the perfect starting point for setting up the first service in the distributed architecture that will deliver that new feature.

Microservices readiness: Understanding the value and investment

What value does the existing application provide?

Adding value is important, but it’s a net-loss if existing value isn’t retained. These could be customer success stories around ease of use and configuration, fast response time in the web application, or a strong security structure. Make sure everyone involved understands what existing value the application provides, and that the key features continue to deliver what customers expect.

How will you measure success?

As you narrow in on who’s impacted by shifting to a distributed architecture, understand that group’s unique business goals. Include these goals in your measure of success and ongoing performance metrics. There are two types of measurements you should be tracking. First are the binary activities, where you only care if something was “done” or “not done.” An example could be employing parallel feature development or the ability of teams to work independently without impacting each other during deployments. Second are ongoing metrics, which track how your microservices architecture performs over time. These metrics could include deployment time, overall downtime, latency, or web app request/response time reduction. Run a test to see if like-sized feature development time is reduced in the microservice versus old technology. You could also measure whether developer turnover is reduced and whether onboarding/ramp-up time for new team members is diminished. Metrics help you quantify whether you’re overcoming obstacles—e.g., whether it’s simpler to deploy things and if it’s better to work with the system than before.

What is your definition of “done”?

This is where most endeavors fail. Unachievable or unrealistic expectations ultimately lead to frustration. Not having a target (no matter how distant) leads to the team wandering aimlessly as they try to dismantle the monolith. It’s important to realize that with something as lengthy as setting up a microservices architecture, you can’t quantify the timeline for the entire project at the start. To maintain focus, estimate how long it can take to complete each unique service and understand those timelines. The main takeaway is: Don’t treat this like one big project; the process of building microservices is a journey. After you’ve completed this journey, a new mindset of building in a distributed architecture should persist within the development team and across the wider business.

Microservices readiness: Organizing and preparing your team

Can your teams be independent but collaborative?

Each microservice should have the expert(s) referred to earlier, a strong developer and/or technical lead who has working knowledge of the existing system, and also an architecture team to keep consistency between independent groups. Each group should be capable of operating autonomously while staying aligned with the vision set by the architecture team. As the project is underway, tiered management and communication/governance plans need to be established: Set up ongoing check-ins within and between groups. Independent groups will collaborate to reach a “shared vision,” and the business should be kept aware of the wins, so the microservice doesn’t become a “black box.” Make sure the new governance and communication structure is reserved for all things related to the microservices. This allows teams to share learnings and achieve greater success over time.

Is the PM side agile (not just dev)?

Ensure your PMs have experience with true Agile and don’t lie to yourself. Often, organizations fool themselves into thinking a waterfall methodology that runs quickly or has iterations built-in is agile. True Agile is a mindset focused on getting the most valuable work done as fast as possible, and the ability of teams to adjust to what’s being delivered based on the most urgent needs. The issues you’ll uncover and last-minute re-prioritization inherent in microservices require this. You can’t possibly know everything that needs to be done, which is why Agile is important. Easy questions to ask your team: “Have you ever run kanban, or only scrum? Beyond Agile, do the PMs have experience in multiple implementation methodologies?” These assure the team can apply a methodology most appropriate for the desired outcome. You can embrace scrum, kanban, lean, or six sigma, or create new combinations tailored to what makes sense for the team: That could be “scrumban” or “lean six.” The ability to adapt to new ways of working is what breeds true agility.

Is the development team ready to adopt new technologies?

Efficiencies are gained with new platforms and technologies. Intentionally ignoring new tools because one group is unwilling to adopt something new hinders implementation to the point of failure. Two key benefits of a distributed architecture are the ability to make technology choices based on business needs and a development process that is unrestricted by legacy technology, allowing you to run independent deployments for each service. Microservices readiness means adopting the right mix of technology that brings the greatest benefit.

Are you prepared for a multi-year engagement?

Understand the time and investment setting up a microservices architecture can take. You need to also be prepared for a more diverse infrastructure setup: This can mean multiple contracts with different service providers based on what’s best suited for each microservice in the distributed architecture. There will also be significant human capital required. Even if you’re bringing in an external partner, you’ll need to have training for the team that will eventually take over. Be sure to have internal communication plans to build engagement and buy-in from the business. The communication plan needs to answer: “How are you going to show value to the business?” Again, the microservices being labeled a “black box” must be avoided.

Do you understand the impact on your product roadmap?

Prepare for a slowdown in development of new features while building a microservices architecture. It’s a matter of numbers: Teams that rollout features are now dedicated to building microservices. Prepare for changes to feature development and the full product roadmap which may occur when that area of the application is undergoing distribution.

From assessment to action

If you’re feeling overwhelmed, you’re in a good place. Acknowledging the scale and impact of setting up microservices is necessary for success. It can be helpful to bring in software consultants to conduct a thorough and thoughtful assessment that will determine your true microservices readiness. With the foundational understanding that this assessment provides, you can develop a solid plan with quantifiable metrics to track progress. Hitting the target with microservices begins with knowing where the target is.

Contact an expert