For example, are we allowed to select one of the Core application that we are not using, say "Appointment", and totally customize it to a brand new application to save the ODA license?
Are we legally (from license perspective) allow to do so using this approach and any risk on this approach? For example, if we upgrade our Archer to a new version in the future, will our customized "Core" application get overwritten by the newer version?
Andy Wong, you are allowed to customize Core applications anyhow you want as you bought Use Case.
And during upgrade, your customized application won't change unless you modify Task Management module.
However, in case you need to use a new Use Case of the upgraded version, you may need to install new Use Case package and deal with customization practicalities in the Package Manager. Won't be easy, but doable.
Though, if you want official response, please raise this to your Sales Manager or RSA Business Rep.
Andy, for clarification. With Archer there's two type of upgrades; framework which brings all the wonderful things Archer can do and does not touch the use cases core applications. Then there are the Use Case upgrades which are specific to the use cases and it has the potential for undoing some of the customization you have done.
While you are able to do so, taking a sledgehammer to a Core application to turn it into an ODA is not something we recommend you do.Even if you don't currently have a need for the application, what about two, three, or five years down the road? At the point where you do need the application, you've now created a huge pile of headaches for yourself to bring that application's purpose and functionality into the fold.
Gutting a Core app has the following considerations (not all inclusive):
- As already mentioned, what about a future state when you need this app, its configuration, and all it's relationship reinstated?
- Deploying other related Use Cases will still impact the Core module due to GUID matches, but in unknowable ways based on your customization.
- Deploying updates to the Use Cases the Core app is a part of will also alter your configuration in unknowable ways based on customization.
- Core applications contain a number of static, locked, or otherwise protected configurations that cannot be deleted or altered, leaving remnants of it's original purpose in your new solution.
- All of the additional objects in the system (notifications, reports, calculations, permissions rules, DDE rules, etc.) that leverage a field or configuration from the Core module have to be unwound / undone, if even possible as they may be locked.
While doing so may save you the cost of an ODA now, it does not well suit or prepare your platform for the future. This is especially true as we embark on the "Right For Me" journey you have hopefully heard about, where we are changing the way in which Archer delivers out of the box applications that are able to grow and unlock with your programs as they mature and evolve.
Scott Hagemeyer, I believe that every admin/developer still does own customization to any core application, because core app cannot fit to all needs/demands of customer. Thus, I believe any type of customization may potentially be a subject to concerns you listed in. However, we still need to do so.
Good comment overall. I believe question here: How many customization can be done to core application to potentially be affected less in a future.
There is a big difference between customization of a Core app to suit business needs, and treating it like an ODA by ripping it entirely apart to a "blank shell". There is no easy way to pin down where that line is drawn.
With the "Right For Me" work we have going on, delivery of Core applications that meet your needs and grow with you over time is the goal. The idea and hope is that we can cut down the amount of customization needed our out of the box, to avoid headaches like this altogether.