Credit: Shutterstock photoWe often get questions from customers and prospects if our application covers the requirements set out in the RFP through standard software, through configurations or through coding/customizations.
There is quite some confusion on the three options (out of the box, configurations, and customizations) so let's start with exploring the differences.
Out of the box:
The most cost effective option is if the requirement is supported out of the box. This means that the software platform can be delivered with a pre-configured use-case, a Best Practice Solution, which instantly works and is matching the client requirements.
Configurations:
It can also be the case that the software needs to be adapted to match the client requirements. In case of configurations the user uses pre-defined methods and tools available in the BWise software to make the changes. This configuration work is not software coding which is a great benefit for all involved. The difference between configurations and customizations is as follows: with configurations the software source code is not modified and with customizations the software source code is modified.
Customizations:
BWise is a commercial-of-the-shelve software platform designed to support multiple Governance Risk and Compliance use cases. We only have one code-base for all our customers; we are not allowing software code changes (customizations) to the platform. At any given point in time we support the latest version of our software and the two previous versions (generally 2 years back). We encourage our customers to upgrade the BWise application frequently - let's say every 6-12 months because of many improvements addressed in each release, like performance & security improvements, and New Features. Flexibility and configurations are engineered into our core product.
Whether we provide our Best-Practice-Solutions, you create your configuration from scratch or rely on one of the solutions provided by 3 rd Parties on the BWise Platform - you're still running the exact same BWise Software. The difference lies in the set of configurations applied to the various layers of flexibility in BWise. These configurations can also easily be transported to other BWise environments (E.g. test/QA/production).
The 'one codebase for all customers' strategy is the right choice for the following reasons:
1. Easy upgrades
Upgrading the BWise software is performed in two steps that should be performed separately. There is a technical upgrade and a functional upgrade.
During the Technical Upgrade the core code of the platform is replaced with a newer version of the software. The actual upgrade usually takes around 1 hour and needs to be followed by a user acceptance test (this can also be automated - but that's a story for another time).
We guarantee that every customer's configuration will continue to work after following the above process. Sometimes an issue is reported - which needs to be resolved by our R&D teams within a reasonable time frame.
After go-live with the newer version of the BWise software - customers can explore all the new features and functions that the new version has to offer and determine which are going to be used in their GRC initiatives - this is the Functional Upgrade phase. Some features are simple toggle switches while others require more configuration effort to be used - and that really depends on the breadth and depth of the envisioned use cases.
2. Robustness
As the same code-base is used by all of our customers we know what functions/features our core platform is supposed to support and therefore we can perform focused performance, security and functional testing against all of those components - making our software more robust.
3. Engineered for best-practices
We adopt only those changes in our core platform that benefit all our customers and follow a common denominator. That means that 95% of customer requirements can usually be met - and in those 5% of the cases we can often argue that it will be included if it fits a best practices serving multiple customers. We want to make sure that the changes are beneficial for the largest group possible.
4. Lower Total Cost of Ownership
Since we do not allow any kind of proprietary software code in the BWise platform - our support/maintenance is very efficient. No additional maintenance requirements incurs if we stick to our principles. Next to that, any improvement we make on behalf of a customer that is considered meaningful to others will become available in the next version therefor benefiting all our customers. We also have customers that are uniting in user-groups to help each other out and find common ground on things that they or we need to improve. We're always open to invitations to join such sessions.
Extended configuration areas in BWise
The entire core code of BWise is written in JAVA and is only changed as part of BWise releases. There are a few areas in our software where we have extended the configuration capabilities for enhancing the flexibility of our software considerably:
- Data stores (SQL)
- Live DWH / Reporting Universe (SQL)
- Formula's (JavaScript)
- UI Definitions (XML)
- Grid TemPLate formatting (TPL's)
- Data Feeds in data feed manager
Coping with more exotic requirements
In some exotic cases we get requirements from our customers that are really specific to their use-cases and inclusion of those functionalities would decrease the benefits mentioned above significantly. We still want to be able to facilitate those customers and that's why most of the functionality in the BWise software is exposed through our Application Programming Interface (API). Customers can extend the capabilities of the BWise platform through using this API in their own custom code. We guarantee the working of the API - the customer themselves (or 3 rd party) is responsible for the custom code. We also provide training on the use of this API. For more information visit www.bwise.com or contact us.
The views and opinions expressed herein are the views and opinions of the author and do not necessarily reflect those of Nasdaq, Inc.
The views and opinions expressed herein are the views and opinions of the author and do not necessarily reflect those of Nasdaq, Inc.
