Being faster at designing and delivering new experiences and products has become one of the main rallying cries of "digital transformation". As a modern organization, you have to stop struggling with the IT side of your goals (or create artificial dichotomies such as "bimodal IT"), and embrace a culture that allows you to move quicker as a business, supported by business-aligned IT.
It is good to be more nimble when it comes to developing new products, which is what Microservice Architecture (MSA) allows you to do. But it also is important to understand that in many cases, customers will interact with more than one product, and thus some form of cross-product quality control is necessary. The term that is increasingly being used for this is Customer Experience (CX), and it is distinctly different from the product-focused perspective of User Experience (UX).
This piece is about the difference of UX and CX, because these are established concepts when it comes to user/customer-facing products. It is worth noting, however, that in the API space, Developer Experience (DX) for APIs and API landscapes follow the same general pattern, and may encounter the same problems. DX in the API space is the equivalent of UX in the UI space, but there is not (yet) a term for "API CX". It seems that the more fine-granular API landscapes are becoming, the more it might necessary to think about "DX across API products". Let us look at a UX/CX scenario as an illustration.
One example is the current crop of native apps. They often are functionally limited, which is understandable because replicating the complete web-based product portfolio of an organization often is not possible or desirable in a single mobile app.
Mobile app product teams often "solve" this problems by sprinkling the native app with links to web-based products, providing these links to the web-based products in an effort to make the missing functionality at least accessible. This is a good idea in principle, but often creates the following CX:
Using the native app (which might have a tested and coherent UI/UX), a customer wants to accomplish something that is not supported in the native app. The app launches a web link, either in an embedded browser, or in the mobile device's regular browser.
The user is taken to a different product, the web app. This often has a different UI/UX approach, and increasingly has a mobile-specific UI/UX. This mobile web app often also is limited in functionality. Assuming the user wants to do something outside of the mobile web app's capabilities, they are now left to search for the "desktop version", which sometimes is almost impossible to find or launch on mobile devices.
Assuming the user found a way to get to the desktop version, they are now in a third UI/UX, often with impossibly small characters and heavily loaded with scripted frameworks that are not working very well on mobile devices.
This process of trying to interact with an organization's products is not that unusual. What's special about it is that is spans three products, and many organizations do not have the right setup to capture and evaluate this CX. Instead, all three product teams (native mobile app, mobile web app, desktop web app) do UX testing specifically for their product, and consequently report great scores for their UX tests.
This problem of a mismatch between a product scope and the scope of what a user wants to do happens for UI and well as for API scenarios. And it is not a problem in itself: It is smarter to avoid integrating everything, because then we are back to the monolith again. However, still having a perspective that's big enough to go across products, and using the right approach to improve CX for the entire product portfolio, that is something that many organizations are still struggling with. It is also something that will increasingly be a good measurement for maturity along the path of digital transformation.
It is a challenge for something as product-focused as MSA to come up with a good story for this cross-product optimization. This may be one of the areas where we will see new practices and patterns emerging, with organizations trying to find the best balance of developing new and engaging products, while still having an eye on the bigger CX picture outlined above.
Personally, I am wondering when the idea of "cross-API DX" will at least be seen as important enough to get its own label. It took a while for "CX" to become a well-known concept, so maybe it will still take a few years before API landscapes and the ease of which they can be utilized have reached the point where these issues are looked at systematically, and get their own names and practices.