Loading in progress.. 
Ovations Configurability
There are many aspects of Cendyn Ovations that set it apart from its competitors in the corporate ticket management space. From our innovation of the space itself nearly two decades ago and our continued longevity; to our knowledgeable and supportive account teams; to our robust and accurate reporting. There are myriad reasons why Cendyn Ovations is the best fit for your ticket management needs, but this post will focus on one of our biggest differentiators: configurability. Below, we will dive in and answer three key questions:
- What do we mean by configurability?
- What are the major benefits of configurability?
- How does Cendyn implement configurability within Ovations?
What is Configurability?
Configurability means that Cendyn Ovations can quickly and easily deploy a solution that is tailored to the exact needs of a diverse array of customers with vastly different business rules and processes and seamlessly adapt as those rules and processes change. It is a core development principle that shapes nearly every update that we make to the application.
We learned very quickly that one of the major challenges of providing ticket management software to multiple Fortune 100 customers in varying sectors of business is that everyone’s needs are a little bit different. Yes, everyone wants a process and application that provides a good experience for end users while still capturing accurate and relevant information for upper management. But information that is relevant for an organization in the financial sector, for example, may not be relevant to an organization in the retail sector. How do we solve this dilemma?
One approach could be to build different requirements into the code for different clients as the needs arise. However, this solution becomes untenable after just a couple of clients are onboarded. The code will quickly become overly-complicated, bloated, and require a lot of maintenance – after all, requirements often change, and with the approach, that change involves ongoing development time and the associated costs.
Another approach is to agree on a set of limited, key data points that are likely to be shared across various companies and industries. This might solve the problem of a complicated codebase, but it comes at the expense of casting aside information that could be key performance indicators specific to a certain industry or client.
If the goal is to have happy customers (spoiler alert: that is our goal), then it’s clear that neither of these options really work. Instead, we developed Ovations in a way that allows us to deploy and maintain a common codebase for all clients while making nearly all aspects of the application configurable. At its simplest, this means we can turn data fields, user permissions, and even entire features on or off at the flip of a switch for one client without affecting others.
What are the benefits of configurability?
As outlined above, configurability solves a major problem. Namely, that each of our current customers and potential future customers will have varying needs, but it’s neither realistic nor practical to build specific requirements into the code every time a new requirement arises or an existing requirement changes.
The benefits of configurability are twofold and apply to both Cendyn and our customers. It benefits Cendyn because when we are asked if we can make a change or enhancement, we can say ‘yes’ without worrying about impact or repercussions to other customers, and we love saying yes. It benefits our customers because it cuts down on time and money spent on custom development. Let’s look at a simple example to help illustrate these points.
At the highest level, each ticket utilized by an employee is categorized into one of several buckets, or order usages. What if different customers have different order usages that they want their users to be able to select from? What if these usages need to vary based on the permissions the user has? What if they need to vary based on the type of ticket being ordered (e.g. suite vs. general admission)? What if they need to vary based on when the order is being placed with respect to the date of the event?
A configurable application is the only way to easily manage all these variables simultaneously, and Ovations has a host of configurations that specifically pertain to order usages.
The list of order usages from which users may select is completely customizable and can be updated at any time.
We can show and hide certain usages based on the role of the user placing the order. For example, only users within the Sales & Marketing department may be able to request tickets for an order usage called Promotions.
We can restrict sensitive assets such as suite tickets from being ordered for personal use.
We can configure usages so that more options are available as the event draws near, effectively allowing you to set and enforce a usage hierarchy.
Lastly, what if any of the rules set up during the initial implementation change after go-live? We’ve got that covered too. Each of the aspects above can be changed without any work from our development team. This means a lightning-fast turnaround from the time new requirements are received to when they are implemented in production and a reduction in (or complete elimination of) the cost of change.
Again, order usages are just one of hundreds of different aspects of Ovations that are designed to be configurable and yield similar results and benefits.
How do we implement configurability within Ovations?
Okay, so if developers aren’t making changes to the code, then how do we do it? Each of our clients have their own set of configurations, separate from each other (Cendyn Ovations customers have their own dedicated databases, so data is not comingled). Cendyn Ovations’ account teams have access to a back-end configuration tool that links directly to the application’s databases and can adjust those configurations. What this means is that rather than hardcoding something, we instead tell the code to read from the configurations for that particular client. The configurations can be updated at any time through a separate user interface, and changes made within the tool are then immediately reflected in the Ovations application.
Going back to the example of order usages, we can get an idea for how this works.
Without a configuration tool, we would need to explicitly list all possible order usages within the code along with all the conditions in which to show or hide those usages to the end user. It would have look something like this:
For Client A, display the following order usages:
Client Entertainment
Promotion
Restrict if role is not Sales & Marketing
Personal Use
Restrict suite tickets
Restrict if > 7 days prior to event date
Charitable Donation
For Client B, display the following usages
Client Entertainment
Sales & Marketing
Executive Use
Restrict if role is not Executive
Government Relations
Restrict if role is not Public Relations
Restrict if value of ticket is > $200
And so on, and so forth, for every client and every possible combination of scenarios that could potentially affect the visibility of the usages. And every time there is a change, that code would need to be updated. It is painful just to think about.
Instead, by reading from the client configurations, the code that displays order usages can be simplified to:
Determine which client is viewing the list
Determine the role of the user viewing the list
Determine the type of ticket being requested
Determine the number of days until the event date
Read from that client’s configurations to display appropriate list of usages based on all those factors
It doesn’t matter how many clients we on-board. It doesn’t matter that those clients all have different usages and rules about how and when to display those usages. That code does not have to change, because it’s the configuration that is changing. Those configurations have been abstracted from the code itself and can be updated on the fly through the configuration tool. Fewer changes to the code means a more stable product and reduced costs for customers.
Conclusion
Every new feature built for Ovations is designed with configurability in mind. Whenever possible, rather than building a new module and forcing each customer to adapt to the change, we instead allow the customer to determine if it’s right for them and enable or disable the feature accordingly. Through this approach, we are able to deliver countless changes to the application on the fly to meet each and every one of our customers’ very specific needs without any negative impact to others.
If you would like to learn more about the configurable options in Ovations or see it in action, please contact ovations@cendyn.com for a demo.