netFORUM Enterprise is a feature-rich system out of the box. But if your organization selected netFORUM Enterprise, they also likely selected it for the flexibility allowed through customizations. Being able to customize means you’re not dependent on a vendor’s roadmap to get the features your organization needs. That said, before you go out and hire a vendor to start adding your amazing new feature, here are five questions to consider about your customization or ask vendors.
1. What would this process look like in baseline?
netFORUM Enterprise is extremely feature-rich. With over of 20 modules, over 900 tables, and 14,000+ columns, there’s likely a lot you didn’t know netFORUM could perform without customization. Before considering any new customizations, take the time to explore what the process would look like in baseline.
This exercise process is easier once you separate the business requirements from the technical requirements. For example, say you need to generate a membership email for any membership purchased. Baseline would not allow you to attach an email to the Membership package. BUT – baseline does allow you to attach an email to a specific product, and if you only have a membership product in each package, those two processes, in essence, accomplish the same thing. If you’re willing to think outside the box with your processes, there’s a lot you can do with netFORUM out-of-the-box functionalities.
2. Will the customization be built using Toolkit or is it custom code?
Not all customizations are made equal. Building out a customization with netFORUM’s Toolkit provides an easier user interface for most changes. When implemented properly, the Toolkit allows you to minimize the need for future code changes and maximizes the baseline footprint that can be upgraded. Also, if you’re extending baseline, you may get the functionality you can reuse to your advantage – see fusionSpan’s Type Ahead plugin which leverages netFORUM’s baseline lookup definition functionality. At the same time, there are certain limitations in netFORUM Enterprise. Sometimes you’ll need a custom control or form extension. This allows you to get exactly what you want, and– particularly in eWeb– may be necessary for an optimal user experience. However, any updates to the customization won’t be simple, and you’ll need a developer for changes. Both have their trade-offs, and sometimes you need a little of both (baseline form with a custom form extension), just make sure you know what you’re getting into before you start.
3. What features will be editable and what is hardcoded?
Unfortunately, more often than not, customizations are built for the now. Which is fine, until the day after you launch when a colleague asks for one more feature or the board decides to “tweak” pricing. Taking the time to build out variability is key to long-term success and limiting costs. If your customization requires a custom code, having built-in flexibility can save you money and time. By adding in little configurations such as adding in system options, setting up tables, or web posts that can drive the customization, you reduce the need for a developer to get involved with every minor tweak. Granted, providing complete flexibility can be costly, so think through your requirements. What are areas of your solution most likely going to need to be tweaked? Prioritize flexibility around those features, and go from there.
4. What is the data structure of the customization?
From a database standpoint, where the data lives likely won’t have a big impact on the customization. Baseline field, extender column, or custom table doesn’t make a huge difference. Until you need to report on the data, and you realize that your customization has been capturing badge name on a custom table and your event name tag pulls ind_badge_name which isn’t being updated. Now you’re scrambling to reconcile Tom with T.J. Figure out early on where your data will live so you can make plans to adjust any reports pulling old data sources, anywhere data may need to be migrated, or any other potential data issues so you’re not scrambling at the last minute.
5. Who will own the code?
Defining code ownership before a vendor starts building your customization is kind of like signing a prenup – it feels a little awkward, but if things ever go south with that vendor you’ll be happy you have it. If you own the code, that means you can turn to another vendor at the drop of a hat and ask them to make changes as opposed to being stuck with a single vendor. In theory a single vendor is fine, but all organizations have turnover, and if your customization is six years old, the developer who worked on your customization left three years ago, being able to get multiple vendors to provide estimates on updating the customization will at the very least give you some negotiating leverage with your current vendor.
6. How will the customization be supported?
Once you launch, the tendency is to say you’re done and move on. Which you can, until a problem comes up. Then you have the difficult conversation of who is responsible for fixing it. While intuitively it should be the vendor, it’s never that simple. With new service packs being applied, and new features being customized, things can break, and they may require additional work that is time and material. Granted, you could sign a support contract with a vendor, but then you have a reoccurring cost related to the customization, which isn’t ideal either. The best you can do is have a clear understanding of expectations going into the process on what will be supported, when will that support end, and what the expectation is once it ends. Having that conversation at the start is always much better than coming back once you have a problem.
Your organization has complicated business needs, so you’ll eventually end up needing to customize. Hopefully, with these questions, you’ll feel more confident heading into conversations with a vendor next time you take the plunge.