There are several projects that do not neatly fit into a single product's target domain. For example let's consider a project that requires beneficiary data management from the field (typical Avni use case), but also requires stock/inventory management of items distributed by the field workers. When creating technical solution for such a project there are following options:
- Find a product that does most and extend it's scope
- Develop a custom solution
- Use two functionally complimentary products
- Integrate two functionally complimentary products but create a new user facing app
In this article we will discuss these options so that we can make a decision.
1. Find a product that does most and extend it's scope
Usually people who have this need approach a product maker (like Samanvay) and enquire whether the project's requirement fits their product. When there is a project, extending the scope of product can be quite tempting (because makers like to make things). The customers, in nonprofits, find it comforting too - that they can just use one product.
But mature product teams will avoid this route because:
- Adding unrelated features to one's product makes the product development unsustainable because of increased complexity.
- Orthogonal features usually get used by very few customers and slowly get less love and the quality deteriorates.
The decision of what goes in the product is a subjective one and the product team is best placed to make that decision. The product teams must explain their rationale to the customers.
2. Develop a custom solution
We have written a lot about this earlier here, where we give reasons for why in most cases for nonprofits this is not a good idea.
3. Use two functionally complimentary products
Before getting into this option, let us further detail our example. In our example project, let's say we have two set of users - field users and stock managers. The field users use the mobile app while they provide service in the field and the stock managers use desktop based web interface.
Potentially, we can use two separate products and give it to each type of users respectively. But what happens when we want the field users to see/manipulate stock data? They can use both apps - field app and the stock management app. But what if the stock management app is not capable of working offline or it is too complex for the user to learn and use two apps. More importantly what if the field users workflows requires managing beneficiary and stock data in the same flow (e.g. fieldworker hands over certain medicines to the beneficiary while doing anaemia screening).
Integrating two products can solve these issues. The field users can capture/view data related to stocks in field app's regular workflows (e.g. filling a form) and let the integration component ensure that the stock management system is updated. But the idea in this approach is not to develop all the stock management screens in field app.
The benefit of this approach lies in reusability of the integration component. The integration component can be generalised to cater to more use cases where there is are similar requirements. This makes the approach sustainable for the development team - as they have to maintain less software and hence for the customer ecosystem too.
4. Integrate two functionally complimentary products but create a new user facing app
Another approach is to not do integration but develop a new user facing app that uses the API of both the products. This approach is useful if the use case is simple. But as the use case becomes complex one may find that one is duplicating the user interface of both the products into this new app.
At Samanvay we have experience of having used option 3 quite a lot. In fact one of the value proposition of Bahmni was that instead of re-developing everything into the product it integrated 3 different products - OpenMRS, OpenELIS, and Odoo. Similarly, we have also integrated Avni with Bahmni using the same idea.
Author: Vivek Singh
Published On: 05 Apr 2023