As part of this week’s post we wanted to switch gears. We thought this would be a good opportunity to open the curtain and show a little bit about the technology and development process behind the scenes at Anevis Solutions and what makes us run.
New clients and prospects often express an interest in topics related to our support, release cycles and development process. And in that vein, we thought it would be interesting for our readers to gain some perspective on the subject of an unified data model, and our unique approach, for this week’s post.
Generally speaking, the idea behind an unified data model (UDM) is a commonly shared data warehouse, that can be utilized across a broad set of clients, in efforts to maximize efficiency. With this UDM, the essence is to identify the commonalities across all clients and create a shared unified data model that can be leveraged more efficiently and in a scalable manner. Most reporting companies on the market work with unified data models, and we do try to encourage our clients to utilize this concept if possible, as it helps tremendously in optimizing the generation process of the reportings. In cases where this works, it can be a win-win situation for both our clients and Anevis Solutions. However, there are quite a lot of circumstances where a generic unified data model using the one size fits all approach won’t be adequate for supporting the particular needs of a specific client.
The methodology of unified data models has some benefits and it has also been demonstrated to work well for a broad spectrum of clients. However, the reality is that there are some clients who are not ready for an upgrade due to backwards compatibility, meanwhile there are others who are in urgent need of the next upgrade as it may contain newly improved functionality that has been requested by them. To solve this duality scenario where there are two different clients with different service needs, we have developed the idea of using a minimal unified data model.
This is important because from a client’s perspective, this enables a dedicated database where client specific requests are incorporated. Additionally, there aren’t constraints to wait for a large periodic release for functionality changes and enhancements. Teams in this case would typically work with the Anevis Solutions support team to have the latest version of the service and have a custom build of the product, with their specifications. This will also include the release cycle for their specific implementation. The key benefit achieved here is not being dependent upon long release cycles you might commonly see for other technology providers. Another important benefit is that this dedicated database and server will ensure business continuity for highly important business services for investment management teams required to share reporting.
While this may cause more maintenance and support on our side (we promise we don’t mind), we have found this to be an optimal solution from the perspective of our clients as they are able to reap the benefits of utilizing a more efficient technology and can essentially have their own dedicated software product, that fully meets their custom specifications. The cherry on top is that no interference to other projects needs to be accounted for and code can be written for specific projects, tested and set live in production without checking if all other projects still run smoothly.
In total, this approach of having an unified data model will offer our clients the benefits of not being tied to other release cycles and greater efficiency in only maintaining one data model, where internal maintenance and onboarding costs are kept to a minimum.
We hope that you enjoyed this article about our minimal unified data model and welcome the questions or comments you have, which can be sent to our support team. Also, if you’d like to read more about this topic and have future articles delivered conveniently to your inbox, please sign up for our newsletter.
