Eleven Technical Requirements to Add to Your Next Software Product RfP
Recently, I was asked to give my input on a RfI (request for information) from a company considering to buy software products off the shelf. They had already divided the functionality they want to see covered into subdomains, and realized that they probably had to buy a number of products covering some of the subdomains, while other subdomains would be better covered by tailor-made applications. As a consultancy company that usually develops or helps to develop the tailor-made applications, we didn’t have any products to offer to the company. But we have often integrated to other company’s products, and have learned what kind of products are easy to integrate with, and what kind of products aren’t.
Below is an excerpt from our response to the RfI, listing our recommendations for the technical requirements that the products should fulfill. Some of them apply to locally installed products only, some of them to SaaS solutions too, while some of them are so universal anno 2021 that they should be followed by tailor-made applications too. I’m sure the list isn’t exhaustive, and as always, your mileage may vary, as they say. Enjoy, and feel free to include them in your next RfP (request for proposal)!
- Open data. All data necessary to fulfill the business requirements should be accessible from the outside, preferably through a well-defined API. Technical data, strictly related to the internal housekeeping of the product and therefore of no influence to the business needs, can be kept internal. We have seen many customers struggle with products that keep their data hidden in proprietary database in undocumented tables, thus hindering smooth integration with other products and applications, and increasing complexity when the time comes for migration to another product or application.
- Open APIs using open data formats. Using open APIs and open data formats makes it much easier to integrate with a product. This applies both to custom-made integration (e.g. in an application) and integration using an integration platform. As for the latter, if open APIs and open data formats are used, there are usually connectors available that make integration in some cases a matter of simple configuration. REST (RESTful, RESTish, yes, I know…) with JSON is currently the de facto industry standard, but shouldn’t be a hard requirement.
- Asynchronous communication whenever possible and appropriate. Whether asynchronous communication is appropriate has to be considered from case to case based on the functional requirements, but generally speaking, asynchronous communication improves the ease of communication and fault tolerance.
- Event-oriented communication. Instead of sending around full business objects, products and applications should strive to send out events to their subscribers when something of interest happens. The events should include at least the essential information to process the event. If possible, all information to process the event should be included, but not if it leads to messages becoming too large.
- Support for zero trust. It should be possible to secure the communication with a product, even for integration purposes, such that the confidentiality and the integrity of the data in the product isn’t necessarily compromised even when somebody manages to enter the secure zone where the product has been deployed.
- Federation of identities. Federation of identities ensures a better identity lifecycle management, both in terms of creation, management and deletion. It is also the basis to enable SSO (single-sign on) for the end-users using the product. If possible and appropriate, federation of groups should also be possible for high-level authorization purposes. Fine-grained authorization is usually closely related to the local domain, certainly if it is attribute-based, and can therefore be handled internally in the product.
- Unless SaaS, products should be cloud-ready, if not cloud-native, even if they are to be deployed on-premises initially. On-premises deployment of cloud-native products and applications can be done in a private cloud, and often offers better scalability than solutions that aren’t cloud-native.
- Unless SaaS, products should support IaC (infrastructure as code). This means that it should be possible to install and configure the product in a new environment from a description file, and it should be possible to do reconfigurations as changes to the description file. This should at least be possible for high-level configuration.
- Low-level configuration should be compatible with version control systems. This means that it should be possible to externalize the complete configuration to a text file that is merge- and diff-friendly for the most common version control systems. It should also be possible to configure the product back again from such a configuration file, but manual steps to restore such a configuration are acceptable. Typical text formats to use for this purpose are YAML, JSON and XML. Git is currently the de facto industry standard for version control systems.
- Products should offer a basic health check service. Such a service should at least be able to respond with the version of the product and that it is up and running. More advanced health checks can provide more data, like e.g. the health of the internal database. It should be avoided that a business service has to be used to monitor whether a product is up and running and available for requests.
- Externalizable logs. This enables log aggregation to products like Elasticsearch. The logs should contain correlation IDs, such that log messages from different products related to the same business request can be related together. This also improves the possibility to monitor the health of the products. Sensitive information should not be included in the logs though, or at least minimized as much as possible.
