Using microservices as a strategic business asset will fail if technology is the only consideration. Eighty-six percent% of digital transformations are failing, not because of poor technology decisions but because of a lack of focus on all of the key aspects that are critical to driving value from these services: the technology strategy, the direct and indirect users of the technology, and outcomes that the technology was put in place to drive.
This multi-threaded strategy is a circular feedback loop, not a linear progression. The measurement of progress against defined outcomes must be used to inform the technical strategy to course correct or cancel projects where the desired results are not being achieved — and for the lessons from the most successful projects to be fed back into future designs. For example, every time Facebook releases a new feature, they set success metrics such as “10 percent of the Facebook population must adopt this feature within three months” for it to be considered a success. If that goal is not hit, then this allows Facebook to course correct early on or minimise future losses by removing it.
Let’s dig into the three areas above and understand the core components that form the strategy and the stakeholders of each.
Technology
Whilst not an exhaustive list, there are some key areas for which a plan must be in place for the microservice strategy to set yourself up for success.
- Successful deployment and training of key technology platforms, e.g. Kong Enterprise
- Target state microservice architecture defined
- Roadmap of projects outlining how the target state will be achieved
- Microservice best practises defined, documented and shared (e.g. what is a microservice in your organisation, how to version, a definition of “done” including publication in internal and external portals)
- Microservice lifecycle defined, documented and shared (e.g. how will services be designed)
- Owners and roles defined for key technologies such as Kong Enterprise, as well as each part of the microservice lifecycle in line with the operating model
A word of caution here: it’s easy to fall into the trap of analysis paralysis and spend too much time defining the strategy before you start delivering use cases and results. In this case, investment in technology is usually considered a failure and requirements will have moved by the time a strategy has been agreed upon. One must take a pragmatic approach, defining enough to get the first project off the ground but not defining too much to build in rigidity; a core part of success is the feedback loop of continuous improvement and change within outcome-based goalposts.
At this step, we also define platform-level success metrics, measuring the usability of the microservice estate. Typical examples are service availability, throughput and response time.
Users
Investment in technology is wasted — and can even reduce productivity and create friction — if the users and consumers of the technology aren’t supported as it is rolled out. Adopting a microservice-based estate requires a culture change. This is often the hardest, and therefore the slowest, part of any transformation; this type of change can have both a positive and negative emotional impact on our teams. It is just as important that we have a strategy for our users as we do for the technology and plan a series of activities with each group of users to bring them on the journey with us.
It is common for companies starting their microservice journey to focus on the experience of external consumers; however, it is often the companies who only focus there that see the least value. Most service traffic is in fact internal; Netflix, for example — a commonly cited example of a great microservice-based architecture — shut its public API in 2014.
It is critical, therefore, for every company to treat internal users with just as much importance as external users, whether they are employees consuming APIs (typical north/south traffic patterns) or services consuming services (typical east/west traffic patterns). For each of our services, this means they must be easy to find, easy to access and easy to use, as well as functional and reliable. But this is not enough — we cannot just build and expose services and expect them to be adopted.
We need to consider what the impact of change is for each of our types of users and evangelise and support them accordingly. First, identify who these groups are: likely, they will fall into one or many of the following:
- Internal and/or external API designers
- Internal and/or external API developers
- Internal and/or external API operators (also called APIOps or DevOps)
- Internal and/or external API consumers
- Product/application owners
- Business/exec sponsors
For each of these groups, identify how engaged we need them to be (stakeholder mapping can be helpful here) and then schedule activities with them, such as hackathons, brown bag lunches, roadshows and consultation groups. Each group will need different levels of engagement activities, so part of the plan is to identify which activities will be most impactful for which groups. This depends on the personalities of the individuals as well as the relationship the microservice platform owners will need to have with each group depending on use cases and projects.
Within each of these groups, identify a champion and a benevolent cynic to validate and harden your strategy and maintain regular communication with them throughout the microservice programme; their feedback will enable you to assess effectiveness and refine your approach accordingly.
Successful user engagement is key to achieving a high rate of adoption and therefore improving productivity, and these are two example metrics we can use to gauge how each of your user groups is adapting.
Outcomes
How do you know that the investment you’re making in adopting microservices is a success unless you know what “success” means? The need to be more agile and efficient, expand product and service offerings digitally, and provide better experiences are what’s driving companies to adopt microservices as part of their digital transformation. It is therefore crucial we can link the execution of our microservice initiatives back to these objectives; otherwise, it’s impossible to demonstrate any ROI, react quickly, fail fast or adapt your strategy as you learn lessons along the way (which is guaranteed to happen).
Given that microservices are intangible assets, it can be difficult to properly measure their impact. However, these are some of the common outcomes they can help you drive:
- Speed and operational efficiency
- Developer experience
- Security and governance
- Insight and intelligence
- Architectural flexibility
Your intended outcomes must be guided by your overall business objectives and reasons for implementing a microservice strategy in the first place. We create a mapping from the top-level business objectives to those above in the context of your services and define success metrics in each of the categories; for example, measuring the level of service reuse because the more you reuse rather than rebuild, the more efficient you become. Some of these outcomes aren’t directly quantifiable, but we can and should still measure the impact of them, such as tracking developer experience by retention rate. For each of our KPIs, we also agree to a measurement frequency.
There are some typical success metrics that are common across many companies — for example: time to market for projects, revenue growth through digital channels and APIs, and time to onboard new developers and partners. It’s important to note, however, that the majority of the metrics you set should be dictated by what your company is trying to achieve, and therefore, there is no one-size-fits-all. The list of measurements you take may also change over time as your microservice programme matures.
Just as important as measuring your success is identifying the individuals across the organisation who are accountable for achieving those outcomes. Without owners, it’s easy for them to be lost as other areas of work are prioritised, which means it’s much harder to keep the microservice part of your digital transformation on track.
Conclusion
As you plan for transformation, it is critical to have defined the outcomes you need to achieve and how you are going to get there. There must be accountable owner(s) for this overall strategy spanning the technology, the users, and the outcomes and accepted feedback mechanisms between each.
Delivering on a microservice strategy is not a linear journey; it is a continuous loop that should start off by acknowledging what it’s meant to achieve. Your progress against your outcomes must be regularly measured and used to refine your technical strategy, and you must ensure you are regularly engaged with all your user groups as your programme matures.
It may feel more comfortable to put a detailed plan in place before getting the first few projects started, but this can derail you before you’ve even begun. Instead, define the first version of the key artifacts up front and use the first projects as an MVP to get you started, and feed the lessons you learn back in to evolve your ongoing strategy.
