‘Feature Requests’ within enterprises
A ‘Feature Request’ is any comment, feedback, or request for additional features by the users of a product. The users who use the product may find a bug in the system and may report the same, suggest improvements to the product, or even request new features depending on their unique requirements. Whatever may be the classification of the user’s voice, they essentially play an important part in shaping the product. How the requests are handled may determine the success of the product.
‘Feature Requests’ however have traditionally been only in the product world. In this post, I would like to extend this idea to Enterprises as well.
This will be a multi-part blog post. In this first post, I will just discuss why Enterprises too need ‘Feature Requests’.
I will borrow the definition of ‘Enterprise’ from TOGAF
“A good definition of “enterprise” is any collection of organizations that has a common set of goals and/or a single bottom line. In that sense, an enterprise can be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership”
Take any enterprise and you will find a lot of heterogeneous applications. These applications interact with each other. There are a few ways in which an application can interact with another (1) directly access the data source of the source application (2) interact via APIs (3) for some legacy applications with no access to its data sources, via Robotic Process Automation (RPA). Sounds simple enough right? From a technical perspective, this is straightforward. Choose an option and make it happen.
However, the problem starts when you realize that every application has an application owner who is responsible for maintaining the application. This includes bug fixes, feature additions, scalability of the application, Performing Disaster Recovery tests, etc. essentially keeping the lights on. Oh, and there is a yearly budget that the application owner works with for maintaining the application. If the application is standalone, meaning built for a particular purpose without any upstream or downstream applications then it is a different story but more times than not, we have upstream or downstream applications that depend on data from the source application. Here, the interface for sharing data becomes crucial.
The application that has the data to be exposed (let’s call it the source application) will have to cater to the various demands of destination applications requiring its data. With a limited budget at the application owner’s disposal, prioritization of requests becomes necessary. Today the decision of prioritization is done on the Cost-Benefit analysis of the application requesting data. Most of the time this is not based on factual data but rather on the political mileage and connections that the destination application owner has. Even though there are several feature requests that come in via emails/tickets, most of them are ignored and not even accounted for next year’s budgeting. This is where the concept of ‘feature requests’ can help.
Let’s consider an example of a custom Policy Management System which exposes data via APIs. Naturally, there will be a lot of processes in an insurance enterprise that will need the policy information. New API methods or changes in the schema will be required all the time. These requests when not prioritized lead to the downstream systems either using a Data Engineering pipeline to duplicate the data from the source system thereby duplicating data and all the problems that come with it or using RPA to screen scrape the information required from the UI which is most of the times fragile. Both of these add a lot of costs, not to the source application but to the enterprise. Consider many such downstream systems requiring similar data and ending up having alternate methods to get to them. The cost to the enterprise is huge. Consider if these requests were aggregated via a ‘Feature Request’ portal and voted by all the downstream applications requiring the same feature, there will be visibility for the feature and hence may have better prioritization, thereby cutting huge costs for the enterprise.
But ‘Feature Requests’ in enterprise bring its own challenges since we are not talking about a single product but a host of applications (products) maintained by different application owners
- How to solicit ‘Feature Requests’? What would be the fields in the form of a feature request? Would the fields have to be different for different applications?
- Who would prioritize a feature? What would be the composition of the oversight committee?
- How would the prioritization happen both within the application and at an enterprise level?
- How the budget allocation to an application be influenced by this and the cost-benefit for the enterprise?
I will try and handle the above questions as separate blog posts so stay tuned!
