A lot of times, as the technical team in a company, you get pressured to build a self-service tool so that business/product-team can perform their configuration and content changes without involving the tech team.
Should you just build what the business/product teams requested or should you justify why this should not be done in the interest of both the business and the tech team and ultimately in the interest of your end customers?
To question the requirements from your product/business teams, you need to have very good justifications and counter proposals. In a good work environment, the requirements should not just come from business and be executed by the tech team. It should be a two way conversation. The perception is that the tech team just wants to deal with technical details, but the reality is that the tech team wants to be involved at the idea phase before the requirements get baked and turned over for design and implementation. Early in my career I was happy with just focusing on technical details and enjoying the process of solving problems through coding. Then later I realized that my motivation comes from knowing what the business team wants to achieve and for me it meant that I was able to translate that to a much better working software.
Let’s use the Price & Product Configuration and its UI tool as an example. This subject is very dear to me and I have certain vision that I would like to share in order to get to the essence of this article.
Let’s assume you built a set of microservices and database structures behind each service to support the following capabilities:
- * Creating offers (no UI but configurable) and specifying the price
- * Creating benefits/features (no UI but configurable)
- * APIs that allows you fetch offers and query offers in order to decided what offer(s) to display to customers
- * API that allows you fulfill offers and ultimately create customers’ subscription records
Let’s say these feature are very stable in production, but you still need to continue to iterate and build new capabilities and enhance existing capabilities for the business requirements that are geared towards the end customers.
At the same time you maybe getting business requirements that are are about the self-servicing of these features for internal customers (your product and business team). These requirements are all about above mentioned capabilities of microservices and introducing some UI tool that allows the business team to perform price and product configuration (creating offers, creating benefits, configuring and changing prices for offers, …etc).
The goal purely looking from the tech team’s angle is to have agility and to innovate. When you introduce UI tools on top of your evolving microservices, then it really slows down your ability to innovate and adapt quickly. Why does the building of a UI tool slow you down? Think about the possible impacts if you change the underlining functionality and structure of your microservices:
- * You will also need to change the UI to accommodate for these changes
- * You will need to possibly train the users of UI if the changes are drastic enough
- * And you will need to roll this out without causing too much disruption.
All of this requires a lot of effort and coordination. This effort and coordination is acceptable after you have a mature product in production, but it is too much overhead if you are still rapidly evolving.
If you have a choice, you really need to consider delaying any self-service UI tools for your business until the data structure and microservices for your data structures are mature enough; otherwise, you would be just slowing down the delivery of new features in these microservices for end customers even though the tech team can deliver all the changes that the UI tool would do for business users by just making application config changes. This is a very good alternative during this crucial innovation phase.
Therefore, as the tech team you need to be able to convey this message to your business and propose investments into the capabilities of these microservices for end customers before building a self-service UI tool. But at the same time, you need to provide to business some visibility to the configuration from these microservces so they can better visualize what what capabilities they have so far. That could be just a BETA version of some simplistic UI tool that is about purely REAL-ONLY information . If it is a “read-only” version of this tool, then the effort is much lower and there is less to consider from the security point of view. Overall, I think this is a good compromise for some amount of time to keep the agility at a high level and to keep the innovation going.
Let’s go back to the days when Google released the beta version of GMail. They kept the beta version for quite some time and they informed users that they don’t have any obligations to support customers requests. Why did they do this? They did it because they did not want to slow down the innovation of GMail in its early days by introducing the formal UI; that’s why kept it as a beta version. I am not saying that you should be doing this for as long as Google has done it, but the overall conclusion is the same.
In conclusion, consider delaying building the official self-service UI tools for your product/business users in order to keep the innovation and agility at a high pace during crucial phase in the evolution of your microservices and data structures/configurations.
Thank you for reading this article. Please follow me here on Medium.com or check out my personal blog: http://www.almirsCorner.com
Almir Mustafic
No comments:
Post a Comment